FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-11-2012, 03:09 PM
Steven J Long
 
Default Council meeting summary for 3 April 2012

Rich Freeman wrote:

> On Tue, Apr 10, 2012 at 10:28 PM, Steven J Long
> <slong@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 ;-)
 
Old 04-11-2012, 04:10 PM
Steven J Long
 
Default Council meeting summary for 3 April 2012

William Hubbs wrote:
> Another issue to consider is binaries that want to access things in
> /usr/share/*. If a binary in /{bin,sbin} needs to access something in
> /usr/share/*, you have two choices. move the binary to /usr or move the
> thing it wants to access to / somewhere which would involve creating
> /share. Actually there is another choice, but I don't want to go there.
> That would be writing patches.
>
I'm ignorant of which binaries do that? (It's understood that you might not
have manpages in rescue-mode.) OT, it's odd that nano is in /usr/bin but on
my system at least it only links to /lib64.

We're only discussing the same tools one might need in an initramfs, wherein
they presumably also need to have their linkage checked.

> The best way to solve all cross / - /usr dependencies imo is the /usr
> merge (moving everything from /{bin,sbin,lib*} to the counterparts in
> /usr), which has been discussed pretty extensively on this list, and
> there hasn't been a lot of opposition to it.
>
There's been quite a bit of vocal opposition on the forums[1], and it's
users who've setup their machines in line with Gentoo docs that this is
going to impact. Even the link that was given to Red-Hat discussion about
this a while back, showed opposition to the move from their users.

[1] http://forums.gentoo.org/viewtopic-t-914852.html
'It's about as good an idea as putting the entire content of /etc into a
file and calling it "The Registry"
Oh, wait, that's already been done and shown not to work.'
NeddySeagoon - whose experience in system-administration and IT I'll bow to
anyday.

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
 
Old 04-11-2012, 04:55 PM
Rich Freeman
 
Default Council meeting summary for 3 April 2012

On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> 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.

The issue is that if udev requires libfoo, then libfoo must not be in
/usr. If libfoo is libx11 or dbus or some other complex library, that
will pull in a bunch of other stuff as well. However, I doubt that
the maintainers of all those libraries would consider them
boot-essential, so they may not be inclined to make the move.

Obviously we're not there now, but it is a possible consequence of
moving in this direction.

Keep in mind that systemd in particular does not aim to be
cross-platform - they advertise this as one of their core features.
Since tight integration is their goal that could slowly bring in a lot
of other stuff. The main platform pushing it along is Fedora, and
they're aiming to move everything into /usr, so this is a non-issue
for them.

> 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?

I can't really comment on what the decision from the Council actually
was. However, maintaining patches to udev is effectively the same
thing as forking it. Right now it probably isn't hard, and over time
that could change.

The only time patches != fork is if the patches have been submitted
upstream and are likely to be merged.

In any case, it isn't a crisis now and waiting a little to see which
way the wind ends up blowing probably makes sense.

Rich
 
Old 04-11-2012, 07:57 PM
Zac Medico
 
Default Council meeting summary for 3 April 2012

On 04/11/2012 07:13 AM, Steven J Long wrote:

Zac Medico wrote:


On 04/10/2012 07:28 PM, Steven J Long wrote:

I suppose you could script that, but again, it just seems like a lot of
bother to implement an "alternative" that doesn't actually gain anything
over the traditional setup (plus making sure that partitions are mounted
before udev starts.)


At least in the case of udev, we gain from not having to maintain a fork.


"Making sure that partitions are mounted before udev starts" is a lot less
of an ask than setting up an initramfs, and changing the way we've worked
for years. It's what you proposed: an earlymounts init script, or patches to
Gentoo initscripts to do the same thing. Neither involves any patches to
udev proper, so no fork needs to be maintained.


It's not generally practical to do mounts prior to starting udev, since
udev can may be needed to create the device nodes that are needed for
for performing the mounts. Maybe a subset of users can get away with it
by relying on devtmpfs and having the drivers built into the kernel, but
that won't work for everyone.

--
Thanks,
Zac
 
Old 04-22-2012, 02:43 AM
Steven J Long
 
Default Council meeting summary for 3 April 2012

Zac Medico wrote:

> On 04/11/2012 07:13 AM, Steven J Long wrote:
>> Zac Medico wrote:
>>
>>> On 04/10/2012 07:28 PM, Steven J Long wrote:
>>>> I suppose you could script that, but again, it just seems like a lot of
>>>> bother to implement an "alternative" that doesn't actually gain
>>>> anything over the traditional setup (plus making sure that partitions
>>>> are mounted before udev starts.)
>>>
>>> At least in the case of udev, we gain from not having to maintain a
>>> fork.
>>>
>> "Making sure that partitions are mounted before udev starts" is a lot
>> less of an ask than setting up an initramfs, and changing the way we've
>> worked for years. It's what you proposed: an earlymounts init script, or
>> patches to Gentoo initscripts to do the same thing. Neither involves any
>> patches to udev proper, so no fork needs to be maintained.
>
> It's not generally practical to do mounts prior to starting udev, since
> udev can may be needed to create the device nodes that are needed for
> for performing the mounts. Maybe a subset of users can get away with it
> by relying on devtmpfs and having the drivers built into the kernel, but
> that won't work for everyone.

OFC not: the generic method is to use an initramfs. But many of us *do* have
the drivers for the device nodes built-in: it's part of the initial setup in
configuring a kernel (manually) and getting it to boot.

I can't speak for others, but that level of control is why I, for one, chose
Gentoo in the first place. I don't see the need for a source-based distro to
include everything and the kitchen-sink: that principle applies via USE-
flags, and it applies via having a lean kernel that doesn't contain modules
for 15 PCI controllers my motherboard doesn't have, and never could have.

The Council has voted that Gentoo continue to support that subset, without
an initramfs.

I'm glad you accept that we don't need to fork udev to do this, though, so
there isn't that maintenance issue, beyond Gentoo initscripts (and if there
should be in future, a Council member has already committed to overseeing
that work.)

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
 
Old 04-22-2012, 02:53 AM
Rich Freeman
 
Default Council meeting summary for 3 April 2012

On Sat, Apr 21, 2012 at 10:43 PM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> The Council has voted that Gentoo continue to support that subset, without
> an initramfs.

Citation, please?

Rich
 
Old 04-22-2012, 03:30 AM
Steven J Long
 
Default Council meeting summary for 3 April 2012

Rich Freeman wrote:

> On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long wrote:
>> 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.
>
> The issue is that if udev requires libfoo, then libfoo must not be in
> /usr. If libfoo is libx11 or dbus or some other complex library, that
> will pull in a bunch of other stuff as well. However, I doubt that
> the maintainers of all those libraries would consider them
> boot-essential, so they may not be inclined to make the move.
>
> Obviously we're not there now, but it is a possible consequence of
> moving in this direction.
>
Sure, but I'm curious: how would you set up an initramfs under those
conditions?

Where I'm going with this, is that in both cases (an initramfs or a
traditional rootfs system) we need to be aware of what libs pull in what.
Given that, there is actually common work both sides need.

If we could focus on that, we'd all actually be cooperating to fix things
for both setups, instead of arguing about which is best.

> Keep in mind that systemd in particular does not aim to be
> cross-platform - they advertise this as one of their core features.
> Since tight integration is their goal that could slowly bring in a lot
> of other stuff. The main platform pushing it along is Fedora, and
> they're aiming to move everything into /usr, so this is a non-issue
> for them.
>
I have a feeling that "integration" is being used as an excuse to avoid
thinking about coupling and cohesion.

>> 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?
>
> I can't really comment on what the decision from the Council actually
> was.

Well, I've stated that several times now, and included the snippet from the
log where Betelgeuse specifically asked Chainsaw to clarify that a
"universal" minimal initramfs was not good enough, which was confirmed.

If Council members disagree with that interpretation, I'd welcome their
clarification.

Split /usr with lvm was specifically discussed as a use-case, since it has
been outlined in Gentoo documentation.

> However, maintaining patches to udev is effectively the same
> thing as forking it. Right now it probably isn't hard, and over time
> that could change.
>
> The only time patches != fork is if the patches have been submitted
> upstream and are likely to be merged.
>
udev != openrc or any other init system, which is what we are patching[1] so
that udev is not started til after localmount, should the user set a
currently unsupported udev.conf option (initramfs="no").

We're only making minor shell-script modifications to udev and udev-mount
initscripts, not openrc itself.

Earlymounts[2] is simply an additional initscript.

IOW no patches to udev whatsoever, so no fork.

> In any case, it isn't a crisis now and waiting a little to see which
> way the wind ends up blowing probably makes sense.
>
No indeed: those of us who wish to stay with our traditional setup, who have
already configured our machines to localmount with built-in modules, can use
the patched initscripts/earlymounts. What we'd like is for those, or
equivalent functionality, to be maintained within Gentoo so we don't have to
tweak patches whenever udev-init-scripts is updated, or in the earlymounts
case there appear to be more issues, and those could use input from devs
imo.

I prefer the patched approach, even if it is a bit more setup and I am
biased, since it appears to have less potential for interaction with other
stuff: if you never needed an initramfs before, and can localmount with just
kernel-created device-nodes (eg: you need to change fstab from using
/dev/vg/lv to /dev/mapper/vg-lv for lvm), then you're fine.

[1] http://forums.gentoo.org/viewtopic-t-901206.html
[2] http://forums.gentoo.org/viewtopic-t-918466.html
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
 
Old 04-22-2012, 05:28 AM
Steven J Long
 
Default Council meeting summary for 3 April 2012

Rich Freeman wrote:
>> The Council has voted that Gentoo continue to support that subset,
>> without an initramfs.
>
(The "subset of users" being those who do not need udev before localmount.)

> Citation, please?
>

<ulm> New udev and separate /usr partition
<Chainsaw> In my opinion, a separate /usr partition has been a supported
configuration for a very long time and should remain so.
<Betelgeuse> Chainsaw: So to clarify a universal initramfs is not enough?
<Chainsaw> Betelgeuse: No. That is additional work for a clearly broken
package.

So we must support separate /usr *without* an initramfs.

<dberkholz> who's going to either "port" udev as necessary, or maintain an
old version forever?
<Chainsaw> I will keep an old version going until the end of time.
<Chainsaw> dberkholz: My plan is to patch reasonable behaviour back into
udev, and going with the upstream releases as long as it is feasible.

To confirm again, that this is about without initramfs:
<dberkholz> sure i can. maintain old udev-XXX forever, put an elog in new
udev that says "if you want separate /usr without initramfs, install old
udev, mask new, or whatever"

And again, I ask: if it were *not* about running udev without an initramfs,
then why would anyone even be discussing the possibility of patching or
forking?

The only question is whether running without an initramfs means the same
thing as not requiring udev before localmount. I contend that it is, since
the basic requirement we've been given is that udev as a service requires
/usr and /var mounted before starting, since some devices already require
scripts which are in /usr or access /var (and going forward effectively can
require a script anywhere.)

Wrt udev linking to /usr/lib, it seems that any such linkage would need to
be satisfied in an initramfs too, so the same data could be used for people
who don't have an initramfs (how we deal with it on our systems is up to
us.)

I would dearly love to hear a walkthrough of how you deal with device nodes
created by udev which are required for udev to start in your initramfs, but
it does not affect the basic requirement for our use-case: that udev is not
needed for localmount.

Regards,
Steve.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
 
Old 04-22-2012, 06:00 AM
Mike Gilbert
 
Default Council meeting summary for 3 April 2012

On Sun, Apr 22, 2012 at 1:28 AM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> Rich Freeman wrote:
>>> The Council has voted that Gentoo continue to support that subset,
>>> without an initramfs.
>>
> (The "subset of users" being those who do not need udev before localmount.)
>
>> Citation, please?
>>
>
> <ulm> New udev and separate /usr partition
> <Chainsaw> In my opinion, a separate /usr partition has been a supported
> configuration for a very long time and should remain so.
> <Betelgeuse> Chainsaw: So to clarify a universal initramfs is not enough?
> <Chainsaw> Betelgeuse: No. That is additional work for a clearly broken
> package.
>
> So we must support separate /usr *without* an initramfs.
>
> <dberkholz> who's going to either "port" udev as necessary, or maintain an
> old version forever?
> <Chainsaw> I will keep an old version going until the end of time.
> <Chainsaw> dberkholz: My plan is to patch reasonable behaviour back into
> udev, and going with the upstream releases as long as it is feasible.
>
> To confirm again, that this is about without initramfs:
> <dberkholz> sure i can. maintain old udev-XXX forever, put an elog in new
> udev that says "if you want separate /usr without initramfs, install old
> udev, mask new, or whatever"
>
> And again, I ask: if it were *not* about running udev without an initramfs,
> then why would anyone even be discussing the possibility of patching or
> forking?
>

Here is my interpretation: the council voted on the following question:

<ulm> The question is: "Decide on whether a separate /usr is still a supported
configuration."

It did not decide the method that would be used to accomplish this. A
few council members (Chainsaw mainly) expressed a desire to do it
without an initramfs, but an official stance on this was not put
forward.

You are reading into it more that you should.
 
Old 04-22-2012, 09:07 AM
Ulrich Mueller
 
Default Council meeting summary for 3 April 2012

>>>>> On Sun, 22 Apr 2012, Mike Gilbert wrote:

> Here is my interpretation: the council voted on the following
> question:

> <ulm> The question is: "Decide on whether a separate /usr is still a
> supported configuration."

> It did not decide the method that would be used to accomplish this.
> A few council members (Chainsaw mainly) expressed a desire to do it
> without an initramfs, but an official stance on this was not put
> forward.

> You are reading into it more that you should.

Please don't cite single lines without context. My next line in that
log is:

<ulm> as in the agenda

Which says:

| 3. New udev and separate /usr partition (30 minutes)
|
| See [4]: "Decide on whether a separate /usr is still a supported
| configuration. If it is, newer udev can not be stabled and
| alternatives should be investigated. If it isn't, a lot of
| documentation will have to be updated. (And an alternative should
| likely still be provided.)"
|
| [4] <http://archives.gentoo.org/gentoo-project/msg_c96d1b724cd736702820fa5ff1547557.xml>

Ulrich
 

Thread Tools




All times are GMT. The time now is 08:42 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org