Rich Freeman wrote:
> On Tue, Apr 10, 2012 at 10:28 PM, Steven J Long
> <sl...@rathaus.eclipse.co.uk> wrote:
>> As for the burden of ensuring that binaries installed to /{s,}bin don't
>> link to libs in /usr, why not just automate a QA check for that, and let
>> developers decide whether a fix is necessary? After all, core packages
>> that do that even when configured with prefix and execprefix = /, aren't
>> so portable, and Gentoo has always championed "doing the right thing" wrt
>> helping upstream fix portability issues.
>
> The only issue with that logic is that upstream is perfectly aware of
> what they're doing already, and bugs are likely to be closed as
> WONTFIX.
It would only be for packages that are specifically marked, the ones you'd
want in an initramfs. The "fix" is simply making sure the buildsystem
doesn't look in /usr/lib etc when so marked, and checking that binaries
don't link from / to anywhere but /lib*. If they do, it's up to the
maintainer as to whether it's an issue.
You'd only file an upstream bug if the build-system was looking in /usr/lib
despite being told not to (eg when only given -L /lib.) Making sure libs are
available in the right location is down to the distro, same as for the
initramfs.
> So, all the QA checks would do is ensure that we slowly
> start maintaining forks of more and more packages. Right now the
> problem is probably manageable, but I'm not convinced it will stay
> that way. Once upstream developers consider all constraints to be
> removed on their dependencies you could see a lot of stuff getting
> pulled into root if you tried to enforce this rule.
>
That might be true for some Linux-only packages, but I really find it hard
to believe that any upstream targetting more than one OS (just adding a BSD
is enough) with software that could be considered critical (I for one would
include all POSIX utilities as well as basic stuff like mount, fsck and
lvm2) would want to ignore this kind of thing; if the build-system is
ignoring configuration, it's a bug.
Regardless of how Linux might move (and personally I think there is a lot
more opposition to this than devs realise, as it throws the idea behind
userspace compatibility completely out of the window, in that it massively
impacts a generation of *nix working practices, even before one considers
systemd's single-point of kitchen-sink failure) taking away choice from end-
users for no appreciable gain in functionality or efficiency seems like a
bad idea.
I understand that the argument is "this is more efficient for our
development" but we're not talking about every package in the tree. Just the
binaries we might need in an initramfs; making sure their linkage is sound,
is likely to be useful for that case too, since it's an even more restricted
environment.
Wrt constraints on dependencies being removed, I don't really see that as
upstream's job; they simply specify the dependencies required and where they
actually are is up to the distro, and provided to the build by a mechanism
like pkg-config, or just flags from the package manager. Distros always have
been about managing dependencies for us.
> In any case, it sounds like the directive is to keep limping along for
> a while longer,
I read the decision from the Council to be "we will continue to support the
traditional split /usr eg with lvm, and no initramfs" and a Council member
put himself forward to maintain patches to udev to ensure that going
forward, since it is needed in his employment.
Given that we can do it with initscripts, and don't need to fork udev at
all, what's the problem?
It would only be for users who specifically opt in, knowing that they don't
need udev to localmount, and with the awareness that they might need to
configure things-- which any Gentoo user is used to hearing and evaluating.
> and that makes sense anyway until docs/etc are
> improved. I agree with Ralph's suggestion that the newer initramfs
> tools should be stabilized as well.
>
No argument on either of those.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
