Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

2012-04-29 Thread Michał Górny
On Sat, 28 Apr 2012 16:44:57 -0700
Luca Barbato lu_z...@gentoo.org wrote:

 On 10/04/12 11:45, William Hubbs wrote:
  There are binaries in /{bin,sbin} which link against libraries in
  /usr/lib for example.
 
 We could try to have an exact list and figure out exactly what is it
 and how impacting it is. If any of those are needed for early-boot it
 would be something to address nonetheless.

I have already opened bugs for many of them. But the list will increase
in time, and we'll either move a lot of libraries to /lib* or decide to
go the other way.

Did someone mentioned mentioning two cross-linked program/data trees
(well, three or four in our case) with fuzzy classification rules is
against KISS?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

2012-04-29 Thread Luca Barbato
On 28/04/12 23:44, Michał Górny wrote:
 I have already opened bugs for many of them. But the list will increase
 in time, and we'll either move a lot of libraries to /lib* or decide to
 go the other way.

repeat after me EARLY BOOT, as in initramfs. In initramfs you don't have
/usr with everything there because you are supposed to mount it. If you
need something (e.g. a mount helper using libs living somewhere) you
need to put it there, if you don't have a way to be aware of which is
where then you'll have users experiencing problems.

The proper way to fix it is either fix the programs or find replacement
that have less or no dependencies.

 Did someone mentioned mentioning two cross-linked program/data trees
 (well, three or four in our case) with fuzzy classification rules is
 against KISS?

Enumerate them, I'm sick of vague problems.

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero




Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

2012-04-29 Thread Zac Medico
On 04/29/2012 12:04 AM, Luca Barbato wrote:
 On 28/04/12 23:44, Michał Górny wrote:
 I have already opened bugs for many of them. But the list will increase
 in time, and we'll either move a lot of libraries to /lib* or decide to
 go the other way.
 
 repeat after me EARLY BOOT, as in initramfs. In initramfs you don't have
 /usr with everything there because you are supposed to mount it. If you
 need something (e.g. a mount helper using libs living somewhere) you
 need to put it there, if you don't have a way to be aware of which is
 where then you'll have users experiencing problems.
 
 The proper way to fix it is either fix the programs or find replacement
 that have less or no dependencies.

Maybe it's reasonable for the initramfs to utilize a config file from
/etc of the future root filesystem, but having in depend on files from
the future /usr seems like a strange idea. Wouldn't it make more sense
to bundle all dependencies into the initramfs, so that it's mostly
self-contained, rather than have it be dependent on files from the
future root filesystem (or future /usr)?
-- 
Thanks,
Zac



Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

2012-04-29 Thread Luca Barbato
On 29/04/12 15:40, Zac Medico wrote:
 Maybe it's reasonable for the initramfs to utilize a config file from
 /etc of the future root filesystem, but having in depend on files from
 the future /usr seems like a strange idea. Wouldn't it make more sense
 to bundle all dependencies into the initramfs, so that it's mostly
 self-contained, rather than have it be dependent on files from the
 future root filesystem (or future /usr)?

Well it is a bit unreasonable even rely on foreign /etc.

The root problem is that what you want to use for early boot should not
have huge deps and that assumption fails for a number of reasons, I
guess mostly due the fact who writes some software doesn't expect it to
be run on early boot =\

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero




Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

2012-04-28 Thread Luca Barbato
On 10/04/12 11:45, William Hubbs wrote:
 Also, I am going to reiterate what Greg said. This is not an issue with
 udev, but with the entire linux ecosystem.

As in bluez using dbus and some mount helpers requiring libraries in /usr.

 There are binaries in /{bin,sbin} which link against libraries in
 /usr/lib for example.

We could try to have an exact list and figure out exactly what is it and
how impacting it is. If any of those are needed for early-boot it would
be something to address nonetheless.

 Also, with the appropriate documentation changes, which are being worked
 on (see [1]), I feel that the statement above that newer udev can't be
 stabled should be re-evaluated.

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero




[gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

2012-04-22 Thread Steven J Long
Ulrich Mueller wrote:

 | 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
 
From the first reply:

To clarify, the question is whether or not we support a separate /usr 
_without_ mounting it early via an initramfs.

I hope that settles that particular issue.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)





Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

2012-04-22 Thread Mike Gilbert
On 04/22/2012 05:28 AM, Steven J Long wrote:
 Ulrich Mueller wrote:
 
 | 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

 From the first reply:
 
 To clarify, the question is whether or not we support a separate /usr 
 _without_ mounting it early via an initramfs.
 
 I hope that settles that particular issue.
 

Hmm... I see that in Zac's reply, thanks for that.

Unfortunately, from what I can tell, that clarification was not actually
part of the proposed agenda [5], nor was it directly referenced. So the
subject of the vote still seems open to interpretation.

Ultimately, the council's only power is to stop things from happening
under threat of expulsion from the project. I think it would be a
mistake for this particular council vote to be used as the sole
justification for preventing devs from committing changes that would
require an initramfs for separate /usr support. It simply does not seem
clear enough for that.

[5]
http://archives.gentoo.org/gentoo-project/msg_ac95bed78694852cd09f20a07437b805.xml



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

2012-04-22 Thread Zac Medico
On 04/22/2012 10:55 AM, Mike Gilbert wrote:
 On 04/22/2012 05:28 AM, Steven J Long wrote:
 Ulrich Mueller wrote:

 | 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

 From the first reply:

 To clarify, the question is whether or not we support a separate /usr 
 _without_ mounting it early via an initramfs.

 I hope that settles that particular issue.

 
 Hmm... I see that in Zac's reply, thanks for that.
 
 Unfortunately, from what I can tell, that clarification was not actually
 part of the proposed agenda [5], nor was it directly referenced. So the
 subject of the vote still seems open to interpretation.

Yeah, it almost seems as though the council was being intentionally
vague and leaving things open to interpretation. In response, we had
William post about the = udev-182 tracker [1], to which Tony seemed
to respond positively [2].

[1]
http://archives.gentoo.org/gentoo-dev/msg_015e73cfccbd72fa956a8bdbc2e9cdc0.xml
[2]
http://archives.gentoo.org/gentoo-dev/msg_fb17ccaadc95c7f3f27d0613c13aa04e.xml
-- 
Thanks,
Zac



Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

2012-04-11 Thread Ralph Sennhauser
On Tue, 10 Apr 2012 13:45:04 -0500
William Hubbs willi...@gentoo.org wrote:

 On Sun, Apr 08, 2012 at 03:04:22PM -0700, Greg KH wrote:
  On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
   New udev and separate /usr partition
   
   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.)
 
 There is no disagreement about whether or not separate /usr will be
 supported. No one has said that you can't have a separate /usr
 partition.
 

Isn't meant /usr without initramfs, independent of how broken some
people precieve it?

 Was the council aware of the tracker bug we have open where we are
 tracking the documentation changes explaining how to build an
 initramfs if you have a separate /usr partition [1]?
 

That's an effort I welcome either way. So thanks for that.

 Also, I am going to reiterate what Greg said. This is not an issue
 with udev, but with the entire linux ecosystem.
 There are binaries in /{bin,sbin} which link against libraries in
 /usr/lib for example.
 

With udev-182 its no longer only the ecosystem which produce some
broken products but udev itself which is broken. Otherwise we would
have gone on like we always did, right?

 Also, with the appropriate documentation changes, which are being
 worked on (see [1]), I feel that the statement above that newer udev
 can't be stabled should be re-evaluated.
 

Long term newer udevs will be stabilized and I'm positive it wont take
as long as grub2 or portage-2.2 ;)

There is no particular hurry as far as I know so let's give Chainsaw
some time to look into an udev patch and don't go with the 30 day
with bug fixing rule.

Support for initramfs was rather poor until recently. For instance
dracut-0.17-r3 (haven't tested 0.18 so far) was the first to actually
produce a usable initramfs for me. Thus far I crafted them manually if
needed. Personally I would like to see the initramfs situation further
improved, this includes genkernel and dracut stable on all platforms and
then give it time to let the knowlage spread or alternatively an udev
patch which allows current setups to continue to work before the
council re-evaluates the udev stabilization again.

Cheers
Ralph

 William
 
 [1] https://bugs.gentoo.org/show_bug.cgi?id=407959


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

2012-04-10 Thread William Hubbs
On Sun, Apr 08, 2012 at 03:04:22PM -0700, Greg KH wrote:
 On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
  New udev and separate /usr partition
  
  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.)

There is no disagreement about whether or not separate /usr will be
supported. No one has said that you can't have a separate /usr
partition.

Was the council aware of the tracker bug we have open where we are
tracking the documentation changes explaining how to build an initramfs
if you have a separate /usr partition [1]?

Also, I am going to reiterate what Greg said. This is not an issue with
udev, but with the entire linux ecosystem.
There are binaries in /{bin,sbin} which link against libraries in
/usr/lib for example.

Also, with the appropriate documentation changes, which are being worked
on (see [1]), I feel that the statement above that newer udev can't be
stabled should be re-evaluated.

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=407959


pgpUAdzbT64Xc.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

2012-04-08 Thread Greg KH
On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
 New udev and separate /usr partition
 
 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.)
 
 The council has voted in favour of a separate /usr being supported
 (5 yes, 1 no vote).

What?

 During the discussion, some concerns were raised that we might not be
 able to provide a modified or forked udev version. Chainsaw assured
 that if necessary, he will maintain a udev version that supports said
 configuration.

It isn't udev that is the problem here, it's the loads of other
packages.  udev is just being nice and pointing out that the user has
a problem.

 It was remarked that a solution that comprises both the forked udev
 version (separate /usr) and the latest versions is possible and
 therefore should not block either way preferred by users.

How in the world are you going to support this type of thing, when it
isn't udev that is the issue?

And udev isn't even the problem, all you need is to mount your /usr from
initramfs.  So, the original proposal wasn't even a correct/valid
proposal in the first place.

Papering over the issue, by just keeping udev from reporting the
problem is NOT a valid solution.  You are shooting the messenger here.

greg k-h



Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

2012-04-08 Thread Rich Freeman
On Sun, Apr 8, 2012 at 6:04 PM, Greg KH gre...@gentoo.org wrote:
 On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:

 The council has voted in favour of a separate /usr being supported
 (5 yes, 1 no vote).

 What?

Perhaps the council should be the ones to clarify, but I think the
vote only was for separate /usr being supported.  The irc log seemed a
bit more nuanced than perhaps came out in the summary.  Maybe I'm
misreading it.  I didn't see anything in the log about a decision that
newer versions of udev are not able to be stabled.

So, as to what a separate /usr being supported means, the impression
I got was don't worry if you're running it, you'll have an upgrade
path.  Right now it sounds like the proposed upgrade path is that
some devs will fork udev and keep it running more like the current one
(presumably breaking in the same situations that it already does
today).

 And udev isn't even the problem, all you need is to mount your /usr from
 initramfs.  So, the original proposal wasn't even a correct/valid
 proposal in the first place.

Well, as far as I can tell the proposal that was voted on didn't even
mention udev at all, or initramfs.  But, as you point out using an
initramfs is likely to be more reliable.

I'm sure the same arguments were going around back when people were
advocating for dropping bootloader support in the kernel and telling
people to bugger_off_msg.  An initramfs creates more flexibility, at
the cost of an extra layer of software, just like grub.  The main
downside to it is that it tends to require more maintenance, though if
you build the necessary drivers to mount /usr into the kernel I
imagine that an initramfs would probably work across differing kernel
versions.

In any case, we should still be updating documentation/etc regardless.
 A better guide to dracut/genkernel would be useful no matter how this
turns out.  I'd like to see stable Gentoo stay current with udev in
any case, but I don't mind using a forked version as long as it is of
similar quality to the original.  As you've pointed out already, that
may not actually help people with a separate /usr, so I'd encourage
people to get an initramfs working.

Rich