[gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Greg KH]

On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote:
> Handling separate /usr support
> ==============================
> After the discussion on [1] during the previous meeting, a delay of one
> month due to a new fork of udev was requested.  We need an update on
> what's happened.
> 
> Chainsaw reported udev and eudev have moved on, and for both it is now
> possible to have a separate /usr.  The follow-up discussion related to
> the /usr-merge is necessary.

udev was never the problem of having a separate /usr without an initrd.
Have all of the other packages been properly fixed to resolve this issue
correctly?

Also, what's the plan for eudev going forward?

thanks,

greg k-h

Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 14/12/12 01:28 PM, Greg KH wrote:
> On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote:
>> Handling separate /usr support ============================== 
>> After the discussion on [1] during the previous meeting, a delay
>> of one month due to a new fork of udev was requested.  We need an
>> update on what's happened.
>> 
>> Chainsaw reported udev and eudev have moved on, and for both it
>> is now possible to have a separate /usr.  The follow-up
>> discussion related to the /usr-merge is necessary.
> 
> udev was never the problem of having a separate /usr without an
> initrd. Have all of the other packages been properly fixed to
> resolve this issue correctly?
> 
> Also, what's the plan for eudev going forward?
> 


Eudev's project announcement is coming soon, should answer your questions.

In terms of udev's dependencies, yes, the few dependencies that were
installing only to /usr (ie, kmod and xz-utils) have been switched to
install to /, and then fixed again due to issues with they way they
were done the first time so that they also work.  I believe however
they are still ~arch keyworded.

There may of course be other entirely independent packages needed at
boot time prior to localmount, I do not know that status of those.
Once eudev (the gentoo package) fully supports separate-/usr (which it
doesn't at this time as it uses the same init scripts as udev-196), we
will be sure to resolve them.

It should be noted that sys-fs/udev (the package) since ..  186 I
think?  whichever version dropped support for the failed-rules queue
(and whichever package dropped the udev-postmount init script) does
not support booting with a separate /usr.  This has more to do with
how the package installs than the upstream code itself, though; as
such (WilliamH please correct me if I'm wrong) the plan is still to
require an initramfs if using sys-fs/udev with a separate-/usr.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlDLeHcACgkQ2ugaI38ACPCErAEAug/ESN7UT1ll76ey9o2ZeNh4
khuFMK8Q5NsUiQBn9ukBAMA9ZeCQ5RqkaaKqEg9mMRDaaDUFepDWFisEhZBjNLy4
=iWNA
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2458 bytes --]

On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 14/12/12 01:28 PM, Greg KH wrote:
> > On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote:
> >> Handling separate /usr support ============================== 
> >> After the discussion on [1] during the previous meeting, a delay
> >> of one month due to a new fork of udev was requested.  We need an
> >> update on what's happened.
> >> 
> >> Chainsaw reported udev and eudev have moved on, and for both it
> >> is now possible to have a separate /usr.  The follow-up
> >> discussion related to the /usr-merge is necessary.
> > 
> > udev was never the problem of having a separate /usr without an
> > initrd. Have all of the other packages been properly fixed to
> > resolve this issue correctly?
> > 
> > Also, what's the plan for eudev going forward?
> > 
> 
> 
> Eudev's project announcement is coming soon, should answer your questions.
> 
> In terms of udev's dependencies, yes, the few dependencies that were
> installing only to /usr (ie, kmod and xz-utils) have been switched to
> install to /, and then fixed again due to issues with they way they
> were done the first time so that they also work.  I believe however
> they are still ~arch keyworded.
> 
> There may of course be other entirely independent packages needed at
> boot time prior to localmount, I do not know that status of those.
> Once eudev (the gentoo package) fully supports separate-/usr (which it
> doesn't at this time as it uses the same init scripts as udev-196), we
> will be sure to resolve them.
> 
> It should be noted that sys-fs/udev (the package) since ..  186 I
> think?  whichever version dropped support for the failed-rules queue
> (and whichever package dropped the udev-postmount init script) does
> not support booting with a separate /usr.  This has more to do with
> how the package installs than the upstream code itself, though; as
> such (WilliamH please correct me if I'm wrong) the plan is still to
> require an initramfs if using sys-fs/udev with a separate-/usr.

Greg, can you write back to this message with specific examples of what
would need to be customized so that separate /usr would work  right
without an initramfs? I have tried to explain multiple times that this
is a mis-conception that udev caused it, but I am getting nowhere.

Thanks,

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Greg KH]

On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote:
> On 14/12/12 01:28 PM, Greg KH wrote:
> > On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote:
> >> Handling separate /usr support ============================== 
> >> After the discussion on [1] during the previous meeting, a delay
> >> of one month due to a new fork of udev was requested.  We need an
> >> update on what's happened.
> >> 
> >> Chainsaw reported udev and eudev have moved on, and for both it
> >> is now possible to have a separate /usr.  The follow-up
> >> discussion related to the /usr-merge is necessary.
> > 
> > udev was never the problem of having a separate /usr without an
> > initrd. Have all of the other packages been properly fixed to
> > resolve this issue correctly?
> > 
> > Also, what's the plan for eudev going forward?
> > 
> 
> 
> Eudev's project announcement is coming soon, should answer your questions.

Ok, when is "soon"?  I'm guessing that the result of the council meeting
ment that things are progressing, right?  If so, in what way?

> In terms of udev's dependencies, yes, the few dependencies that were
> installing only to /usr (ie, kmod and xz-utils) have been switched to
> install to /, and then fixed again due to issues with they way they
> were done the first time so that they also work.  I believe however
> they are still ~arch keyworded.

I am not referring to udev's dependancies, that was never the real
issue with a separate /usr/ partition as those could easily be fixed
with a configuration option for the package.

> There may of course be other entirely independent packages needed at
> boot time prior to localmount, I do not know that status of those.

That's the big problem, those need to be fixed.

> Once eudev (the gentoo package) fully supports separate-/usr (which it
> doesn't at this time as it uses the same init scripts as udev-196), we
> will be sure to resolve them.

Again, udev itself was never an issue, it could work just fine with a
separate /usr/ partition.  Now perhaps our ebuild didn't build it in
that matter, but that's a configuration/ebuild issue, not a upstream
package issue.

> It should be noted that sys-fs/udev (the package) since ..  186 I
> think?  whichever version dropped support for the failed-rules queue
> (and whichever package dropped the udev-postmount init script) does
> not support booting with a separate /usr.  This has more to do with
> how the package installs than the upstream code itself, though; as
> such (WilliamH please correct me if I'm wrong) the plan is still to
> require an initramfs if using sys-fs/udev with a separate-/usr.

If the plan is still to require an initramfs (hint, it's the only way it
can work), then why was the eudev package forked and created?

Please, I'm totally confused now, especially after reading the commits
in the eudev repo, I see nothing that fixed any /usr/ problems, what am
I missing?

Oh, you also slowed the build time of the package down in eudev compared
to udev, but I'm sure you realized that already, and did it for a good
reason.

confused,

greg k-h

Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Greg KH]

On Fri, Dec 14, 2012 at 01:28:00PM -0600, William Hubbs wrote:
> On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> > 
> > On 14/12/12 01:28 PM, Greg KH wrote:
> > > On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote:
> > >> Handling separate /usr support ============================== 
> > >> After the discussion on [1] during the previous meeting, a delay
> > >> of one month due to a new fork of udev was requested.  We need an
> > >> update on what's happened.
> > >> 
> > >> Chainsaw reported udev and eudev have moved on, and for both it
> > >> is now possible to have a separate /usr.  The follow-up
> > >> discussion related to the /usr-merge is necessary.
> > > 
> > > udev was never the problem of having a separate /usr without an
> > > initrd. Have all of the other packages been properly fixed to
> > > resolve this issue correctly?
> > > 
> > > Also, what's the plan for eudev going forward?
> > > 
> > 
> > 
> > Eudev's project announcement is coming soon, should answer your questions.
> > 
> > In terms of udev's dependencies, yes, the few dependencies that were
> > installing only to /usr (ie, kmod and xz-utils) have been switched to
> > install to /, and then fixed again due to issues with they way they
> > were done the first time so that they also work.  I believe however
> > they are still ~arch keyworded.
> > 
> > There may of course be other entirely independent packages needed at
> > boot time prior to localmount, I do not know that status of those.
> > Once eudev (the gentoo package) fully supports separate-/usr (which it
> > doesn't at this time as it uses the same init scripts as udev-196), we
> > will be sure to resolve them.
> > 
> > It should be noted that sys-fs/udev (the package) since ..  186 I
> > think?  whichever version dropped support for the failed-rules queue
> > (and whichever package dropped the udev-postmount init script) does
> > not support booting with a separate /usr.  This has more to do with
> > how the package installs than the upstream code itself, though; as
> > such (WilliamH please correct me if I'm wrong) the plan is still to
> > require an initramfs if using sys-fs/udev with a separate-/usr.
> 
> Greg, can you write back to this message with specific examples of what
> would need to be customized so that separate /usr would work  right
> without an initramfs? I have tried to explain multiple times that this
> is a mis-conception that udev caused it, but I am getting nowhere.

It's not my job to do this, nor yours, or fix any of these issues.  It's
up to the people who wish to keep a separate /usr partition without an
initramfs to do this work.

greg k-h

Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Kevin Chadwick]

Firstly I use your longlasting 3.2 kernel currently though perhaps not
for long as I'm switching distro to avoid systemd and thank you for
the LTS work, however that won't stop me speaking my mind.
_____________________________________________________________________

> > Greg, can you write back to this message with specific examples of what
> > would need to be customized so that separate /usr would work  right
> > without an initramfs? I have tried to explain multiple times that this
> > is a mis-conception that udev caused it, but I am getting nowhere.  
> 
> It's not my job to do this, nor yours, or fix any of these issues.  It's
> up to the people who wish to keep a separate /usr partition without an
> initramfs to do this work.


So even though you keep stating things without being specific like
udev is not a blocker, you have just admitted that the udev package
does violate the Filesystem Hiearchical Standard as well as the latest
draft when installing. I can understand following the current trend
(some of which I agreed with) but what is the justification for that
which didn't already have an optional solution?

It's not your job?. I'd hope your unix spirit or atleast professionalism
would be greater than this and realise that helping may save good devs
time more than it costs you and realise that the generic goals may not
be everyone's or even the long lasting correct ones and competition is
good and not intended as a kick in the teeth or insult.



p.s. embedded does not equal mobile and android uses a leaner init
than /sbin/init and experiments posted to the buildroot list found
systemd to be slower, guessed to be due to increased cycles but perhaps
memory usage on even some mobile level processors which accounts for a
fraction of linux potential in embedded applications. POSIX compliance
is also a requirement by some major industries.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

[gentoo-dev] Re: [e]udev , and please let's move this to a better location (was: Summary Council meeting: Tuesday 11 December 2012)

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 14/12/12 03:02 PM, Greg KH wrote:
> On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote:
>> 
>> Eudev's project announcement is coming soon, should answer your
>> questions.
> 
> Ok, when is "soon"?


It's being drafted as we speak, so it will probably be released within
a few days.  I'm not authoring it so I can't give you an exact time
for when the announcement will be posted.


> I'm guessing that the result of the council meeting meant that
> things are progressing, right?  If so, in what way?


Sounds like you should join us in #gentoo-udev to discuss, or join the
eudev mailing list.  I'd rather not spend a significant amount of time
writing about eudev development on gentoo-dev@ given it's not really
on-topic here.


>> In terms of udev's dependencies, yes, the few dependencies that
>> were installing only to /usr (ie, kmod and xz-utils) have been
>> switched to install to /, and then fixed again due to issues with
>> they way they were done the first time so that they also work.  I
>> believe however they are still ~arch keyworded.
> 
> I am not referring to udev's dependancies, that was never the real 
> issue with a separate /usr/ partition as those could easily be
> fixed with a configuration option for the package.


Understood, but they still needed to be fixed (their packaging).

(I expect most issues regarding separate-/usr-without-initramfs
support will be about fixing packaging)


>> There may of course be other entirely independent packages needed
>> at boot time prior to localmount, I do not know that status of
>> those. Once eudev (the gentoo package) fully supports
>> separate-/usr (which it doesn't at this time as it uses the same
>> init scripts as udev-196), we will be sure to resolve them.
> 
> That's the big problem, those need to be fixed.
> 


Agreed.

However as i'm looking at this from the eudev perspective at this
point, rather than the sys-fs/udev perspective, there are things
necessary to integrate into eudev (the gentoo package, and possibly
also the code) itself before we as the eudev team are ready to see
what else is broken and needs adjustment.



>> It should be noted that sys-fs/udev (the package) since ..  186
>> I think?  whichever version dropped support for the failed-rules
>> queue (and whichever package dropped the udev-postmount init
>> script) does not support booting with a separate /usr.  This has
>> more to do with how the package installs than the upstream code
>> itself, though; as such (WilliamH please correct me if I'm wrong)
>> the plan is still to require an initramfs if using sys-fs/udev
>> with a separate-/usr.
> 
> If the plan is still to require an initramfs (hint, it's the only
> way it can work), then why was the eudev package forked and
> created?


This is the plan for sys-fs/udev in gentoo (sorry i'd thought i was
clear on that, i apologize if I wasn't), sys-fs/eudev maintainers
intend to support separate-/usr without initramfs to the best of our
abilities.


> Please, I'm totally confused now, especially after reading the
> commits in the eudev repo, I see nothing that fixed any /usr/
> problems, what am I missing?


You're not missing anything -- eudev is still a WIP and doesn't have
the support for separate-/usr yet (either in the codebase or in the
gentoo package).  We're working on it.  It'll be in place by the time
we have a full release tagged.

For further details (and as stated above) I suggest we discuss on irc,
via the eudev mailing list, or via email directly.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlDLlY4ACgkQ2ugaI38ACPB52gD/d2E2WL2ZYxadGswJIqP3nqqW
Co+0ua+G5yXQ8+lFiP4A/248opPpMkzm1pEklhJBUvaVrZ7JW3xWSLOpKOPs6iQr
=xy6w
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Everyone, given we already went through a major bikeshed a month ago,
let's not do it again...?

On 14/12/12 04:00 PM, Kevin Chadwick wrote:
> 
> [ Snip! ]
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlDLlfAACgkQ2ugaI38ACPBEyAD+KU3unjYTmevc2SRVCZDH9eZ2
nrpgstesBNH7KG6bcsMBAJwE+vsPQJouMQA6tQ8xzCpM7s929+fk4R+AQh96b0Gd
=zTGa
-----END PGP SIGNATURE-----

[gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Duncan]

Greg KH posted on Fri, 14 Dec 2012 12:04:03 -0800 as excerpted:

> n Fri, Dec 14, 2012 at 01:28:00PM -0600, William Hubbs wrote:
>> On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote:
>> > On 14/12/12 01:28 PM, Greg KH wrote:

>> > > udev was never the problem of having a separate /usr without an
>> > > initrd. Have all of the other packages been properly fixed to
>> > > resolve this issue correctly?

>> > It should be noted that sys-fs/udev (the package) since ..  186 I
>> > think?  whichever version dropped support for the failed-rules queue
>> > (and whichever package dropped the udev-postmount init script) does
>> > not support booting with a separate /usr.  This has more to do with
>> > how the package installs than the upstream code itself, though; as
>> > such (WilliamH please correct me if I'm wrong) the plan is still to
>> > require an initramfs if using sys-fs/udev with a separate-/usr.
>> 
>> Greg, can you write back to this message with specific examples of what
>> would need to be customized so that separate /usr would work  right
>> without an initramfs? I have tried to explain multiple times that this
>> is a mis-conception that udev caused it, but I am getting nowhere.
> 
> It's not my job to do this, nor yours, or fix any of these issues.  It's
> up to the people who wish to keep a separate /usr partition without an
> initramfs to do this work.

There's a saying, extreme claims require extreme proof.  I don't 
personally have a stake in this as by personal policy my root includes 
/usr, but... for (1) people who had a separate /usr, who then (2) had 
that break with a udev upgrade, and (3) saw the very high visibility 
claims that despite the evidence of their own eyes, udev was *NOT* what 
broke things...

To these people, the claim that udev was NOT what broke (non initr*) boot 
of a separate /usr system, looks rather extreme.

Yet the people who made that claim both:

1) Continue to make it, just as strenuously and high visibility as they 
did before, and

2) Continue to try to shift responsibility for proving evidence for that 
claim, despite the (a) "I was THERE!" evidence many have that a udev 
update is what broke things for THEM and (b) the high visibility yet 
evidently "extreme" (from the point of view of those who saw the breakage 
happen with a udev update) claims to the contrary.

There's a discontinuity there.  Either udev wasn't the problem and those 
claiming it was should be easily able to provide a list of (non-corner-
case) examples where it was broken previously, or udev WAS the problem, 
as they "I was THERE!" evidence of many users suggest.  Yet those making 
the (to those that were "there") extreme claim continue to avoid 
providing appropriate evidence to back it up, saying it's not their job 
to provide such evidence, despite the /apparent/ extremity of their claim.

This sort of /apparent/ illogic and refusal to justify apparently 
arbitrary decisions only contributes to the unfortunate situation.

Oh, well, both the making of sausage and the making of law is said not to 
be pretty, who ever expected the making and evolution of FLOSS platform 
software to be pretty.  Surprisingly, despite the issues, we always seem 
to muddle thru, and the problems eventually resolve themselves to a 
reasonably stable situation of either a major dominance of one solution 
(see xorg/xfree86), or of competing multiple solutions (see emacs/vi or 
kde/gnome/xfce/...), over time.  Regardless of any temporary angst, I 
suppose the same will ultimately apply here.  From a third party 
perspective, however, some of that angst sure seems unnecessary. <shrug>

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Ralph Sennhauser]

On Fri, 14 Dec 2012 12:02:40 -0800
Greg KH <gregkh@gentoo.org> wrote:

> On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote:
> > On 14/12/12 01:28 PM, Greg KH wrote:
> > > On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote:
> > >> Handling separate /usr support ============================== 
> > >> After the discussion on [1] during the previous meeting, a delay
> > >> of one month due to a new fork of udev was requested.  We need an
> > >> update on what's happened.
> > >> 
> > >> Chainsaw reported udev and eudev have moved on, and for both it
> > >> is now possible to have a separate /usr.  The follow-up
> > >> discussion related to the /usr-merge is necessary.
> > > 
> > > udev was never the problem of having a separate /usr without an
> > > initrd. Have all of the other packages been properly fixed to
> > > resolve this issue correctly?
> > > 
> > > Also, what's the plan for eudev going forward?
> > > 
> > 
> > 
> > Eudev's project announcement is coming soon, should answer your
> > questions.
> 
> Ok, when is "soon"?  I'm guessing that the result of the council
> meeting ment that things are progressing, right?  If so, in what way?

Why would it matter if soon meant a week or a month from now?

> 
> > In terms of udev's dependencies, yes, the few dependencies that were
> > installing only to /usr (ie, kmod and xz-utils) have been switched
> > to install to /, and then fixed again due to issues with they way
> > they were done the first time so that they also work.  I believe
> > however they are still ~arch keyworded.
> 
> I am not referring to udev's dependancies, that was never the real
> issue with a separate /usr/ partition as those could easily be fixed
> with a configuration option for the package.
>

If some vocal upstream and otherwise respected maintainers claim it to
be broken and calls everyone a fool for not following suite, that's what
we get. ;)
 
> > There may of course be other entirely independent packages needed at
> > boot time prior to localmount, I do not know that status of those.
> 
> That's the big problem, those need to be fixed.

But there is no hurry as separate /usr is broken for years, right?

> 
> > Once eudev (the gentoo package) fully supports separate-/usr (which
> > it doesn't at this time as it uses the same init scripts as
> > udev-196), we will be sure to resolve them.
> 
> Again, udev itself was never an issue, it could work just fine with a
> separate /usr/ partition.  Now perhaps our ebuild didn't build it in
> that matter, but that's a configuration/ebuild issue, not a upstream
> package issue.
> 

udev not only could work just fine with a separate /usr but potentially
make it a non issue. Let's see if eudev succeeds here. If it's the right
place to solve it is another question, though the right place for udev
isn't in systemd either.

> > It should be noted that sys-fs/udev (the package) since ..  186 I
> > think?  whichever version dropped support for the failed-rules queue
> > (and whichever package dropped the udev-postmount init script) does
> > not support booting with a separate /usr.  This has more to do with
> > how the package installs than the upstream code itself, though; as
> > such (WilliamH please correct me if I'm wrong) the plan is still to
> > require an initramfs if using sys-fs/udev with a separate-/usr.
> 
> If the plan is still to require an initramfs (hint, it's the only way
> it can work), then why was the eudev package forked and created?
> 

sys-fs/udev is systemd-udev, hope we don't have to rename the package
to make this clear.

> Please, I'm totally confused now, especially after reading the commits
> in the eudev repo, I see nothing that fixed any /usr/ problems, what
> am I missing?
> 

The sentence in the very same mail that it's currently not working /
implemented maybe?

> Oh, you also slowed the build time of the package down in eudev
> compared to udev, but I'm sure you realized that already, and did it
> for a good reason.

That's always the last straw, speeeeeeeed!

> 
> confused,
> 
> greg k-h
> 

Seriously, while I agree the eudev fork had an ivory tower start, I
don't get what you gain by running around like an elephant in a
porcelain shop. I for one welcome yet another fork. Time will tell if
it can prevail.

Regards
Ralph

Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Greg KH]

On Fri, Dec 14, 2012 at 09:00:56PM +0000, Kevin Chadwick wrote:
> > > Greg, can you write back to this message with specific examples of what
> > > would need to be customized so that separate /usr would work  right
> > > without an initramfs? I have tried to explain multiple times that this
> > > is a mis-conception that udev caused it, but I am getting nowhere.  
> > 
> > It's not my job to do this, nor yours, or fix any of these issues.  It's
> > up to the people who wish to keep a separate /usr partition without an
> > initramfs to do this work.
> 
> So even though you keep stating things without being specific like
> udev is not a blocker, you have just admitted that the udev package
> does violate the Filesystem Hiearchical Standard as well as the latest
> draft when installing.

Specifically how does udev violate it?  And also note, FHS is a trailing
standard, documenting how things are done, not how they should be done.
It can be changed.

And since when did Gentoo start worrying about FHS and LSB?

> I can understand following the current trend (some of which I agreed
> with) but what is the justification for that which didn't already have
> an optional solution?

I don't understand, what in the udev package, or source, goes against
FHS?

> p.s. embedded does not equal mobile and android uses a leaner init
> than /sbin/init and experiments posted to the buildroot list found
> systemd to be slower, guessed to be due to increased cycles but perhaps
> memory usage on even some mobile level processors which accounts for a
> fraction of linux potential in embedded applications. POSIX compliance
> is also a requirement by some major industries.

What does POSIX have to do with anything here?

And when did I bring up systemd and boot times?  That's not what this
thread is about, sorry.

greg k-h

Re: [gentoo-dev] Re: [e]udev , and please let's move this to a better location (was: Summary Council meeting: Tuesday 11 December 2012)

[Greg KH]

On Fri, Dec 14, 2012 at 04:09:34PM -0500, Ian Stakenvicius wrote:
> On 14/12/12 03:02 PM, Greg KH wrote:
> > I'm guessing that the result of the council meeting meant that
> > things are progressing, right?  If so, in what way?
> 
> Sounds like you should join us in #gentoo-udev to discuss, or join the
> eudev mailing list.  I'd rather not spend a significant amount of time
> writing about eudev development on gentoo-dev@ given it's not really
> on-topic here.

It was discussed at the Gentoo Council meeting, how could that _not_ be
on topic here?

greg k-h

Re: [gentoo-dev] Re: [e]udev , and please let's move this to a better location

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 14/12/12 06:24 PM, Greg KH wrote:
> On Fri, Dec 14, 2012 at 04:09:34PM -0500, Ian Stakenvicius wrote:
>> On 14/12/12 03:02 PM, Greg KH wrote:
>>> I'm guessing that the result of the council meeting meant that 
>>> things are progressing, right?  If so, in what way?
>> 
>> Sounds like you should join us in #gentoo-udev to discuss, or
>> join the eudev mailing list.  I'd rather not spend a significant
>> amount of time writing about eudev development on gentoo-dev@
>> given it's not really on-topic here.
> 
> It was discussed at the Gentoo Council meeting, how could that
> _not_ be on topic here?
> 
> greg k-h
> 

Not really, no -- what was discussed at the Council meeting was more
or less verbatum what was said in the summary -- Chainsaw reported
that eudev was progressing, had entered the tree, and that he was
confident that it will fulfill the needs of a udev package in Gentoo
that will support separate-/usr without an initramfs.

Any further details of eudev's implementation and/or development were
not discussed at the meeting and are not something that I believe
Council cares about in any particular way either.  (in fact, the
conversation rather quickly turned to a discussion on the role of
gen_usr_ldscript() rather than anything udev/eudev related)

So, everyone, for more discussion about eudev development, please join
the shiny new eudev mailing list; we'll be happy to get into all the
nitty gritty details there and spare all the dev's that don't care
from having to filter it out of their inboxes.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlDL2okACgkQ2ugaI38ACPAuyAD/esvQcRiUWBeaO8jHyAOvWBp9
yt/2xghT+VGjbpKJmOQA/jpIIoRuCe87k28nvJj1iVSwVALhq9n5dvER3NReR/C/
=8p5A
-----END PGP SIGNATURE-----

[gentoo-dev] gen_usr_ldscript & --libdir=/lib

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1389 bytes --]

On Friday 14 December 2012 05:43:41 Fabian Groffen wrote:
> gen_usr_ldscript() vs --libdir=/lib.  Questions on why, and if it makes
> sense to remove gen_usr_ldscript in favour of --libdir.  WilliamH will
> open a discussion on gentoo-dev ML.

these are orthogonal issues.  not every package using gen_usr_ldscript has a 
--libdir option, and even the ones that do commonly install more than one 
library but we really only want to move one.  plus with static libs, --libdir 
will install those into the wrong place.

so for most packages, the choice is either:
	src_configure() { econf ; }
	src_install() { default ; gen_usr_ldscript -a bar ; }
or:
	src_configure() { econf --libdir=/lib ; }
	src_install() {
		default
		dodir /usr/$(get_libdir)
		mv "${ED}"/$(get_libdir)/lib{f,x}* "${ED}"/usr/$(get_libdir)/ || die
		if use static-libs ; then
			mv "${ED}"/$(get_libdir)/*.{a,la} \
				"${ED}"/usr/$(get_libdir)/ || die
		fi
	}

the only time --libdir=/lib makes sense to use is when the path itself then 
gets used for things other than just the installation of libraries and there's 
no knob to control those other things.  like rules.d files.

i.e. saying "we should get rid of gen_usr_ldscript and use --libdir=/lib" 
makes absolutely no sense.  it's just begging for people to screw things up 
constantly and waste developer time for 0 gain.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

On 24/12/2012 20:08, Mike Frysinger wrote:
> i.e. saying "we should get rid of gen_usr_ldscript and use --libdir=/lib" 
> makes absolutely no sense.  it's just begging for people to screw things up 
> constantly and waste developer time for 0 gain.

Amen.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 553 bytes --]

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

On Mon, Dec 24, 2012 at 10:48:23PM +0100, Diego Elio Pettenò wrote:
> On 24/12/2012 20:08, Mike Frysinger wrote:
> > i.e. saying "we should get rid of gen_usr_ldscript and use --libdir=/lib" 
> > makes absolutely no sense.  it's just begging for people to screw things up 
> > constantly and waste developer time for 0 gain.
> 
> Amen.

Actually, since ulm pointed out in another thread that the
council has not mandated that we support separate /usr without an
initramfs, I am re-considering this.

In linux-only ebuilds, if we install everything in /usr as gregkh and
others have suggested, we can remove this call from them. Also, for the
other ebuilds that have this call, we can eventually disable the
function on Linux systems.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[Tony "Chainsaw" Vroon]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On Wed, 2012-12-26 at 22:01 -0600, William Hubbs wrote:
> Actually, since ulm pointed out in another thread that the
> council has not mandated that we support separate /usr without an
> initramfs, I am re-considering this. 

So now that the /usr-merge steamroller can not break systems through
udev, because an alternative now exists... another way must be found?
That seems rather immature.
What must be forked next to keep this working? openrc?

Regards,
Tony V.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[Rich Freeman]

On Thu, Dec 27, 2012 at 2:55 AM, Tony "Chainsaw" Vroon
<chainsaw@gentoo.org> wrote:
> On Wed, 2012-12-26 at 22:01 -0600, William Hubbs wrote:
>> Actually, since ulm pointed out in another thread that the
>> council has not mandated that we support separate /usr without an
>> initramfs, I am re-considering this.
>
> So now that the /usr-merge steamroller can not break systems through
> udev, because an alternative now exists... another way must be found?
> That seems rather immature.
> What must be forked next to keep this working? openrc?

Tend to agree, assuming it causes no additional work for package maintainers.

This all started out as udev maintainers wanting to keep things simple
and closer to upstream.  Systems with a separate /usr breaking was a
bit of a side-effect.  The general direction that was chosen was to
provide alternatives for those who don't want to use an initramfs and
allow udev to follow upstream.  Life for the udev team is easier as a
result.

There is no decided strategic direction at Gentoo to move everything
into /usr as there is with Fedora.  It just doesn't make sense to
start pushing packages there.  That potentially CREATES work for
maintainers (bug reports, dealing with change, etc), and there is no
real benefit unless we systematically apply it (moving EVERYTHING into
/usr as with Fedora).  Systematically moving everything isn't going to
happen by just changing an eclass.

If somebody can see a benefit to having things moving in the direction
of /usr then by all means stick a flag in the profiles and use it to
control this behavior, and then we give choice to the end-user.
However, I don't really see the point.  When you change the status quo
it should be because it either lowers cost or produces benefit.

Rich

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

On Thu, Dec 27, 2012 at 07:55:38AM +0000, Tony "Chainsaw" Vroon wrote:
> On Wed, 2012-12-26 at 22:01 -0600, William Hubbs wrote:
> > Actually, since ulm pointed out in another thread that the
> > council has not mandated that we support separate /usr without an
> > initramfs, I am re-considering this. 
> 
> So now that the /usr-merge steamroller can not break systems through
> udev, because an alternative now exists... another way must be found?
> That seems rather immature.
> What must be forked next to keep this working? openrc?

Nothing must be forked. No one has said anything is happening yet. This
is just a discussion.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

On Thu, Dec 27, 2012 at 08:00:09AM -0500, Rich Freeman wrote:
> On Thu, Dec 27, 2012 at 2:55 AM, Tony "Chainsaw" Vroon
> <chainsaw@gentoo.org> wrote:
> > On Wed, 2012-12-26 at 22:01 -0600, William Hubbs wrote:
> >> Actually, since ulm pointed out in another thread that the
> >> council has not mandated that we support separate /usr without an
> >> initramfs, I am re-considering this.
> >
> > So now that the /usr-merge steamroller can not break systems through
> > udev, because an alternative now exists... another way must be found?
> > That seems rather immature.
> > What must be forked next to keep this working? openrc?
> 
> Tend to agree, assuming it causes no additional work for package maintainers.

As I and others have said on this list a thousdand times, moving
everything to /usr never had anything to do with systemd and udev. This
is a completely separate topic.

The arguments for moving everything into /usr seem to be pretty strong
[1], and as gregkh and others have said, it would benefit us in the longrun
to do it.

Given that, that is not even what I'm discussing. I am just discussing
moving the libraries that we manually install into /lib* back to
/usr/lib* on Linux.

William

[1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[Mike Gilbert]

On Thu, Dec 27, 2012 at 12:03 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Thu, Dec 27, 2012 at 08:00:09AM -0500, Rich Freeman wrote:
>> On Thu, Dec 27, 2012 at 2:55 AM, Tony "Chainsaw" Vroon
>> <chainsaw@gentoo.org> wrote:
>> > On Wed, 2012-12-26 at 22:01 -0600, William Hubbs wrote:
>> >> Actually, since ulm pointed out in another thread that the
>> >> council has not mandated that we support separate /usr without an
>> >> initramfs, I am re-considering this.
>> >
>> > So now that the /usr-merge steamroller can not break systems through
>> > udev, because an alternative now exists... another way must be found?
>> > That seems rather immature.
>> > What must be forked next to keep this working? openrc?
>>
>> Tend to agree, assuming it causes no additional work for package maintainers.
>
> As I and others have said on this list a thousdand times, moving
> everything to /usr never had anything to do with systemd and udev. This
> is a completely separate topic.
>

It has everything to do with udev if you (as the udev maintainer for
Gentoo) decide to put zero effort into keeping udev working with a
traditional split-/usr configuration. Although udev is only one
package of many, it is a pretty damn critical one.

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

On Thu, Dec 27, 2012 at 01:35:55PM -0500, Mike Gilbert wrote:
> On Thu, Dec 27, 2012 at 12:03 PM, William Hubbs <williamh@gentoo.org> wrote:
> > On Thu, Dec 27, 2012 at 08:00:09AM -0500, Rich Freeman wrote:
> >> On Thu, Dec 27, 2012 at 2:55 AM, Tony "Chainsaw" Vroon
> >> <chainsaw@gentoo.org> wrote:
> >> > On Wed, 2012-12-26 at 22:01 -0600, William Hubbs wrote:
> >> >> Actually, since ulm pointed out in another thread that the
> >> >> council has not mandated that we support separate /usr without an
> >> >> initramfs, I am re-considering this.
> >> >
> >> > So now that the /usr-merge steamroller can not break systems through
> >> > udev, because an alternative now exists... another way must be found?
> >> > That seems rather immature.
> >> > What must be forked next to keep this working? openrc?
> >>
> >> Tend to agree, assuming it causes no additional work for package maintainers.
> >
> > As I and others have said on this list a thousdand times, moving
> > everything to /usr never had anything to do with systemd and udev. This
> > is a completely separate topic.
> >
> 
> It has everything to do with udev if you (as the udev maintainer for
> Gentoo) decide to put zero effort into keeping udev working with a
> traditional split-/usr configuration. Although udev is only one
> package of many, it is a pretty damn critical one.

As I said on another thread, there was a misunderstanding on my part
about setting up udev. I am looking into fixing that with the next
release, but I need to coordinate with systemd as well, so I thought it
would be good to wait for 197 to be released, so again, this is not
correct.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[Rich Freeman]

On Thu, Dec 27, 2012 at 12:03 PM, William Hubbs <williamh@gentoo.org> wrote:
>
> As I and others have said on this list a thousdand times, moving
> everything to /usr never had anything to do with systemd and udev. This
> is a completely separate topic.

Understood.  However, the whole request to not have to support a
separate /usr without an initramfs was brought up by the udev team.
If udev doesn't have the need, then they should just go do what they
want to do and stop asking the council to step in, as there apparently
isn't anything for them to decide on.

>
> The arguments for moving everything into /usr seem to be pretty strong
> [1], and as gregkh and others have said, it would benefit us in the longrun
> to do it.
>
> Given that, that is not even what I'm discussing. I am just discussing
> moving the libraries that we manually install into /lib* back to
> /usr/lib* on Linux.

I think moving everything into /usr is a good idea.  However:

1.  It isn't my decision to make.  This is the role of the Council.
2.  It doesn't make sense for every dev to just stick stuff wherever
they personally feel is best.
3.  Moving just a bunch of libraries to /usr and nothing else is dumb.
 It brings none of the benefits of the /usr move, and gets rid of all
of the benefits of complying with FHS (like systems booting fine with
a separate /usr - and yes I know this is already "broken" despite the
fact that it works just fine for 99% of the people running in this
configuration).  This is one of those situations where you need to
have a plan and do it right, or don't do it at all.

If people want to argue for a /usr move by all means do so.  If people
want to beg the Council to back this, by all means do so.  If people
want to run for Council by all means do so.  If you want to build a
mechanism that gives the choice to the end user based on a profile
setting or some other sensible mechanism, by all means do so.

But, until the Council decides that we're really doing a coordinated
/usr move, then let's leave things alone.  Sticking stuff in random
locations per the whim of individual maintainers will cause nothing
but trouble.

Rich

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3314 bytes --]

On Thu, Dec 27, 2012 at 01:49:50PM -0500, Rich Freeman wrote:
> On Thu, Dec 27, 2012 at 12:03 PM, William Hubbs <williamh@gentoo.org> wrote:
> >
> > As I and others have said on this list a thousdand times, moving
> > everything to /usr never had anything to do with systemd and udev. This
> > is a completely separate topic.
> 
> Understood.  However, the whole request to not have to support a
> separate /usr without an initramfs was brought up by the udev team.
> If udev doesn't have the need, then they should just go do what they
> want to do and stop asking the council to step in, as there apparently
> isn't anything for them to decide on.
 
 I wasn't actually asking the council to step in. I was just trying to
 have a discussion here.

> >
> > The arguments for moving everything into /usr seem to be pretty strong
> > [1], and as gregkh and others have said, it would benefit us in the longrun
> > to do it.
> >
> > Given that, that is not even what I'm discussing. I am just discussing
> > moving the libraries that we manually install into /lib* back to
> > /usr/lib* on Linux.
> 
> I think moving everything into /usr is a good idea.  However:
> 
> 1.  It isn't my decision to make.  This is the role of the Council.

Tell me if I am wrong here. My understanding is that this is only true
if the community itself doesn't make the decision first.

> 2.  It doesn't make sense for every dev to just stick stuff wherever
> they personally feel is best.
> 3.  Moving just a bunch of libraries to /usr and nothing else is dumb.
>  It brings none of the benefits of the /usr move, and gets rid of all
> of the benefits of complying with FHS (like systems booting fine with
> a separate /usr - and yes I know this is already "broken" despite the
> fact that it works just fine for 99% of the people running in this
> configuration).  This is one of those situations where you need to
> have a plan and do it right, or don't do it at all.
 
 Ok, I can agree with this.

> If people want to argue for a /usr move by all means do so.  If people
> want to beg the Council to back this, by all means do so.  If people
> want to run for Council by all means do so.  If you want to build a
> mechanism that gives the choice to the end user based on a profile
> setting or some other sensible mechanism, by all means do so.
> 
> But, until the Council decides that we're really doing a coordinated
> /usr move, then let's leave things alone.  Sticking stuff in random
> locations per the whim of individual maintainers will cause nothing
> but trouble.
 
 There was a long thread a while back where the /usr merge was discussed
 in depth and there was no escalation to the council to make the
 decision [1]. Unless I don't remember something significant out of that
 thread, we agreed that even though some of us don't like the /usr
 merge, it is probably a good thing for us to do it in the longrun.

If I were to start that thread now, I would change my introduction to
not specifically mention udev, systemd and kmod, but my view still is
that it will be better for us in the longrun if we do it. Maybe that is
a topic for another thread though.

William

[1]
http://archives.gentoo.org/gentoo-dev/msg_c3c5bdabbe058b08627ff04cee896af3.xml

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[Rich Freeman]

On Thu, Dec 27, 2012 at 2:48 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Thu, Dec 27, 2012 at 01:49:50PM -0500, Rich Freeman wrote:
>> Understood.  However, the whole request to not have to support a
>> separate /usr without an initramfs was brought up by the udev team.
>> If udev doesn't have the need, then they should just go do what they
>> want to do and stop asking the council to step in, as there apparently
>> isn't anything for them to decide on.
>
>  I wasn't actually asking the council to step in. I was just trying to
>  have a discussion here.

The Council WAS asked to step in:
http://www.gentoo.org/proj/en/council/meeting-logs/20120403-summary.txt
http://thread.gmane.org/gmane.linux.gentoo.project/1864/focus=1867

However, you are right, the udev team did not actually request this.
So, if udev 180+ doesn't break anything that wasn't already broken in
udev 179- then just go about your business...  :)

>> 1.  It isn't my decision to make.  This is the role of the Council.
>
> Tell me if I am wrong here. My understanding is that this is only true
> if the community itself doesn't make the decision first.

True, but I don't see any consensus on this topic.  The /usr move is
VERY controversial, at least within Gentoo.  This really doesn't fall
into the domain of any one project either - this affects the whole
distro.  Even if it did fall into the domain of a single project,
anybody with half a brain would realize that you don't just do
something like this on the initiative of a few individuals unless you
want a really big mess on your hands.

> If I were to start that thread now, I would change my introduction to
> not specifically mention udev, systemd and kmod, but my view still is
> that it will be better for us in the longrun if we do it. Maybe that is
> a topic for another thread though.

Agreed.  There is no harm in discussing it.  I'd love to see this as a
supported Gentoo configuration, and perhaps even as the default.
However, this should come down to a discussion of pros/cons,
especially in terms of what kinds of opportunities it creates.

Something I don't like about this whole debate is that it tends to
come off as "I've never run an initramfs and darn it I want to keep it
that way."  Gentoo has always been a cutting-edge/innovative distro.
We have prefix, hardened, x32, and we were among the first to support
amd64.  Sure, that flexibility also lets you get away without an
initramfs where other distros simply cannot.  However, the lack of an
initramfs should not be a crutch.

I could see the exact same argument unfolding 15 years ago about
forcing users to have a bootloader like grub.  Go bring up the
suggestion that the kernel should support direct booting on lkml and
I'm sure Linus will tell you to bugger_off...

Rich

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[Tony "Chainsaw" Vroon]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

On Thu, 2012-12-27 at 15:14 -0500, Rich Freeman wrote:
> Go bring up the suggestion that the kernel should support direct
> booting on lkml 

And be pointed at EFI_STUB functionality. Next?

Regards,
Tony V.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[Rich Freeman]

On Thu, Dec 27, 2012 at 3:27 PM, Tony "Chainsaw" Vroon
<chainsaw@gentoo.org> wrote:
> On Thu, 2012-12-27 at 15:14 -0500, Rich Freeman wrote:
>> Go bring up the suggestion that the kernel should support direct
>> booting on lkml
>
> And be pointed at EFI_STUB functionality. Next?

I was referring to booting from a legacy BIOS - hence my comment about
15 years ago - back when this was a completely supported linux
configuration.

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1337 bytes --]

On Wednesday 26 December 2012 23:01:46 William Hubbs wrote:
> On Mon, Dec 24, 2012 at 10:48:23PM +0100, Diego Elio Pettenò wrote:
> > On 24/12/2012 20:08, Mike Frysinger wrote:
> > > i.e. saying "we should get rid of gen_usr_ldscript and use
> > > --libdir=/lib" makes absolutely no sense.  it's just begging for
> > > people to screw things up constantly and waste developer time for 0
> > > gain.
> > 
> > Amen.
> 
> Actually, since ulm pointed out in another thread that the
> council has not mandated that we support separate /usr without an
> initramfs, I am re-considering this.
> 
> In linux-only ebuilds, if we install everything in /usr as gregkh and
> others have suggested, we can remove this call from them. Also, for the
> other ebuilds that have this call, we can eventually disable the
> function on Linux systems.

as mentioned in bug 417451, the ebuilds won't drop the `gen_usr_ldscript` 
call.  we'll update the gen_usr_ldscript itself to be a no-op.  that way non-
linux systems continue to work, as well as linux users who want to live in the 
past.

on the upside, i will no longer have compassion for keeping / small, so we can 
close all the existing bugs about "pkg foo in / is linked against lib bar in 
/usr" by dumping these calls.  or maybe we symlink /usr/lib to /lib ? :)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1427 bytes --]

On Thursday 27 December 2012 13:49:50 Rich Freeman wrote:
> I think moving everything into /usr is a good idea.  However:

i don't think it's hard to support both.  the majority of packages just want 
to relocate shared libs into / from /usr and that's easy with one line:
	gen_usr_ldscript -a foo
put a knob into the func itself (perhaps a var set in the profile's 
make.defaults) and you've addressed more than 50% of the problem.

very few packages actually install into /bin and /sbin, and i don't mind a 
USE=sep-usr flag for them (relevant since i also see that i'm maintaining most 
of those packages).

> 3.  Moving just a bunch of libraries to /usr and nothing else is dumb.
>  It brings none of the benefits of the /usr move

sure

> and gets rid of all
> of the benefits of complying with FHS (like systems booting fine with
> a separate /usr - and yes I know this is already "broken" despite the
> fact that it works just fine for 99% of the people running in this
> configuration).

strictly speaking, i don't think FHS mandates sep /usr be supported.  it's 
fairly easy to read a merged /usr setup as being FHS compliant.

> But, until the Council decides that we're really doing a coordinated
> /usr move, then let's leave things alone.  Sticking stuff in random
> locations per the whim of individual maintainers will cause nothing
> but trouble.

aka today's status quo
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

On Thu, Dec 27, 2012 at 03:14:37PM -0500, Rich Freeman wrote:
> Something I don't like about this whole debate is that it tends to
> come off as "I've never run an initramfs and darn it I want to keep it
> that way."  Gentoo has always been a cutting-edge/innovative distro.
> We have prefix, hardened, x32, and we were among the first to support
> amd64.  Sure, that flexibility also lets you get away without an
> initramfs where other distros simply cannot.  However, the lack of an
> initramfs should not be a crutch.

Rich,

you just hit my concern about this debate right on the head. I feel like
the nay-sayers are opposed to it because of the FHS, and the idea of
critical software going in / and everything else in /usr. The attitude
seems to be that has always worked, so it must continue to work into the
future, with no regard to the advantages that moving everything to /usr
would give us.

Another concern I've heard says that we shouldn't do this on linux
because gentoo *bsd doesn't do it. I don't see that as relevant
because ebuilds can be smart enough to test whether they are being
emerged on Linux or *BSD.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]

On 2012.12.27 22:13, William Hubbs wrote:
> On Thu, Dec 27, 2012 at 03:14:37PM -0500, Rich Freeman wrote:
> > Something I don't like about this whole debate is that it tends to
> > come off as "I've never run an initramfs and darn it I want to keep
> it
> > that way."  Gentoo has always been a cutting-edge/innovative 
> distro.
> > We have prefix, hardened, x32, and we were among the first to
> support
> > amd64.  Sure, that flexibility also lets you get away without an
> > initramfs where other distros simply cannot.  However, the lack of
> an
> > initramfs should not be a crutch.
> 
> Rich,
> 
> you just hit my concern about this debate right on the head. I feel
> like
> the nay-sayers are opposed to it because of the FHS, and the idea of
> critical software going in / and everything else in /usr. The 
> attitude
> seems to be that has always worked, so it must continue to work into
> the
> future, with no regard to the advantages that moving everything to
> /usr
> would give us.
> 
> Another concern I've heard says that we shouldn't do this on linux
> because gentoo *bsd doesn't do it. I don't see that as relevant
> because ebuilds can be smart enough to test whether they are being
> emerged on Linux or *BSD.
> 
> William
> 
> 

I don't think the 'luddites' have quite so black and white a view as 
that but if I expand on it much more, I'll reignite a flamewar we have 
already had. 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 301 bytes --]

On Thursday 27 December 2012 17:13:56 William Hubbs wrote:
> Another concern I've heard says that we shouldn't do this on linux
> because gentoo *bsd doesn't do it. I don't see that as relevant
> because ebuilds can be smart enough to test whether they are being
> emerged on Linux or *BSD.

+1
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]