files: track relabeling using set instead of slice

[Nemric]

This PR handle relabelling by preventing multiple relabels ...
The goal is to avoid managing it in the code allowing contributors to call relabelling func without having to check if the path is already included in the "torelabel" slice

[jlebon]

Thanks for the contribution!

I'm not sure if this is worth it. setfiles will handle duplicate entries just fine and in general we shouldn't be generating that many duplicates anyway.

If we really want to make sure that all paths are unique before passing to setfiles, maybe a cleaner approach would be to switch from a slice to a set (really, a map[string]struct{}).

[Nemric]

Yes I understand, so in #1303 I used to code differents things to prevent sending to relabel too many file/path
Bgilbert ask me for a better way to do that by finding the "root" of setting file/path to relabel, that's what this PR is intended to do.
if I well understand, the "action" for relabelling (setfiles) already handle this case ?

[jlebon]

Yes, setfiles itself will work just fine as is.

OK, read some of the discussions in #1303 now. That PR is introducing code which will make it easier to have multiple requests for relabeling the same dirs unless the code is made more complex to handle that.

So I'm cool with embedding handling for this into the relabeling bits directly. For that, let's do

maybe a cleaner approach would be to switch from a slice to a set (really, a map[string]struct{}).

instead?

[jlebon]

That said, I'd consider this orthogonal to #1303. You can go ahead and simplify the code there to just call s.relabel() "inefficiently" for now and we don't have to block it on this necessarily. (Big picture, we're not talking about that many duplicates here, right? Something like user unit * (users for unit - 1) summed across all user units?)

[Nemric]

Yes, we don't speak about a ton of files, you're right :) I just dive in the systemd.unit code and I don't know the amount of files/paths that have to be relabelled when setfiles is called
When I went into debug mode, I saw some duplicates, and we (@bgilbert and I) started to avoid that. (e.g. : #1318 )

So I'm cool with embedding handling for this into the relabeling bits directly. For that, let's do

maybe a cleaner approach would be to switch from a slice to a set (really, a map[string]struct{}).

instead?

I agree for using map against slice but to be honest, I felt lazy handling that 😄 will give it a try ;)

[jlebon]

Looks close! Can you also squash all your commits to a single one?

[jlebon]

Outdated comment. I think the point it makes is still valid for maps, so you can just s/slice/map/.

[jlebon]

Minor: we can use make here instead to preset the capacity since we know how many things we'll add.

[jlebon]

Thanks!

[jlebon]

Sorry, one final thing. Let's tweak the commit message to something like:

files: track relabeling using set instead of slice

That way we avoid passing the same path to `setfiles` multiple times.

?

[dustymabe]

Nice work @Nemric!