On Mon, Mar 07, 2011 at 09:44:47AM +0100, Michaaa GGGrny wrote:
> On Sun, 6 Mar 2011 17:34:29 +0100
> Constanze Hausner <consta...@gentoo.org> wrote:
>
> > On 17:44 Sat 05 Mar , Ciaran McCreesh wrote:
> > > * some filesystems don't support xattrs at all, and the package
> > > manager needs to support installing to them, even if the user is
> > > building on a filesystem that does support it
> >
> > While GSoC I was not able to come up with a good fallback mechanism.
> > I'm going to give the new ideas some thought over the week and
> > hopefully come up with something good :).
>
> How about that:
> 1) src_install() installs a file, like in:
> /var/lib/gentoo/filecaps.d/${PF}
> specifying which caps have to applied to which files,
>
> 2) the eclass depends on an ebuild, installing a kind
> of 'filecaps-apply' tool, reading information from that file and trying
> to apply filecaps as necessary (and flipping setuid bits),
>
> 3) the eclass calls that tool in pkg_postinst() to apply the caps
> on the target filesystem.Exactly what benefit is derived from trying to step outside the PM for this, and trying to hack up what the PM already set for permissions? General rule of thumb, the more the PM knows the better things are going to be for people, and for long term compatibility. If in doubt consider the improvements to user experience via revdep-rebuild functionality making it into the PM; PM can actually plan for rebuilds as it goes rather than potentially blowing up a later build (or telling the user "go run xyz"). Consider: 1) this tool will have to grow system/user configuration for overrides- something the PM could fold in easily enough into it's existing capbilities. If in doubt consider FEATURES=suidctl . 2) has to be prefix aware, including understanding of deprived. This can be done mind you, but like #1, the bits are already there at the PM level. 3) the information recorded there is ultimately redundant when/if a sane VDB format gets created; as is this info could just as easily be pushed in there as a new file per CPV in the existant VDB format. 4) this requires further OOB handling for ID databases- handling that could've been pushed into the PM itself (admittedly a weak point since ID is already mildly screwed up here, but no point in making it worse). 5) it opens up a window in every merge where setuid binaries are on disk, just prior to your proposed tool getting ran. This is annoying to say the least, and if the system has disabled setuid in full it's a window where the binaries aren't actually usable. 6) it's slower than just having the PM do it. Specifically, the PM is already transfering the content to disk, and fiddling it's bits- adjusting the files modes and setting capability is something it can do on creation (eliminating #5) rather than having to shell out to some script. It's important to realize that the area this slows down is a critical section for parallelized binpkg merging- something the chrome-os folk have ran into. 6) shifting it to an external tool means the format used by the tool needs standardization (rather than just being standardized via PMS) to allow interop when inevitably a PM author goes to fold the functionality into the PM. 7) this tool, due to it being not part of the PM, the PM has to go out of it's way to protect the depgraph for- something it should already be doing for itself. External, it's another hardcoded constant (or addition to system set) the PM has to watch for- w/in the pm, it ought to pay attention to it as is. > This should help with all the issues mentioned, including binpkg > support. Moreover, user could use the tool manually to restore/reset > filecaps if they were lost or unapplied (e.g. due to incorrect kernel > config). Every issue you've raised is addressable at the PM level- generally speaking, done better at the PM level. Basically... please fix the problem at the correct location. Capabilities, xattrs, etc, are not a temporary fad- they're increasingly a core requirement of a linux system (thus the PM that manages it). The place for this functionality is in the PM- more importantly, trying to do it outside of it just makes a bigger mess for PM/format authors when inevtiably it has to be pulled in. ~harring
pgpBqFa2A6gfT.pgp
Description: PGP signature
