On Mon, Mar 07, 2011 at 09:44:47AM +0100, Michaaa GGGrny wrote:
> On Sun, 6 Mar 2011 17:34:29 +0100
> Constanze Hausner <email@example.com> 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:
> 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
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
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
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.