[gentoo-dev] Suggestion for getting rid of udev

[gentoo-dev] Suggestion for getting rid of udev

[Walter Dnes]

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

Hi all

  Recently, there was a firestorm on the gentoo-user list over the idea
that udev would eventually require /usr to be on the same physical
parition as /, or else use initramfs, which is its own can of worms. I'm
not a programmer, let alone a developer.  Rather than merely ranting, I
went and searched for an alternative.

  Forking udev is probably not an option.  The udev lead developer is a
Redhat employee, and his direction seems to be to drag everybody in
Redhat's direction.  Our community doesn't have Redhat's billions.

  The other option is to drop udev entirely.  As an example, I suggest
looking at Alpine Linux http://alpinelinux.org/  It's a lightweight
server-oriented distro.  It uses busybox's mdev instead of udev, and
some other mdev substitutes in place of standard packages.  It uses
openrc.  Furthermore, "previous versions of Alpine were based on Gentoo"
as per http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package so
there should be no problem with us borrowing back from Alpine.

  The only reason Alpine isn't usuable for regular users right now is
that it's built with uclibc, which will break closed-source binary blobs
(e.g. Flash and Acrobat and many video card drivers).  I'm not a
developer or programmer, so correct me if I'm wrong, but it shouldn't be
difficult to replace uclibc with the standard library, and build away.

  Another option is to take the current Gentoo setup, drop udev and
use mdev in the same manner as Alpine uses it.  In case anyone asks,
auto mounting should still be possible.  Attached is an excerpt from
/var/log/messages from a basic Alpine install.  The kernel messages were
generated when I inserted a USB key into a usb jack.

-- 
Walter Dnes <waltdnes@waltdnes.org>

[-- Attachment #2: usbkey.txt --]
[-- Type: text/plain, Size: 1645 bytes --]

Oct  9 13:46:00 e521 kern.info kernel: [10714.105621] usb 2-8: new high speed USB device using ehci_hcd and address 4
Oct  9 13:46:00 e521 kern.info kernel: [10714.241353] usb 2-8: New USB device found, idVendor=13fe, idProduct=1e00
Oct  9 13:46:00 e521 kern.info kernel: [10714.241357] usb 2-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct  9 13:46:00 e521 kern.info kernel: [10714.241360] usb 2-8: Product: Patriot Memory  
Oct  9 13:46:00 e521 kern.info kernel: [10714.241362] usb 2-8: Manufacturer:         
Oct  9 13:46:00 e521 kern.info kernel: [10714.241364] usb 2-8: SerialNumber: 078215A302CF
Oct  9 13:46:00 e521 kern.info kernel: [10714.244241] scsi4 : usb-storage 2-8:1.0
Oct  9 13:46:01 e521 kern.notice kernel: [10715.279753] scsi 4:0:0:0: Direct-Access              Patriot Memory   PMAP PQ: 0 ANSI: 0 CCS
Oct  9 13:46:02 e521 kern.notice kernel: [10715.930991] sd 4:0:0:0: [sdb] 31326208 512-byte logical blocks: (16.0 GB/14.9 GiB)
Oct  9 13:46:02 e521 kern.notice kernel: [10715.931980] sd 4:0:0:0: [sdb] Write Protect is off
Oct  9 13:46:02 e521 kern.debug kernel: [10715.931983] sd 4:0:0:0: [sdb] Mode Sense: 23 00 00 00
Oct  9 13:46:02 e521 kern.err kernel: [10715.931986] sd 4:0:0:0: [sdb] Assuming drive cache: write through
Oct  9 13:46:02 e521 kern.err kernel: [10715.935986] sd 4:0:0:0: [sdb] Assuming drive cache: write through
Oct  9 13:46:02 e521 kern.info kernel: [10715.981381]  sdb: sdb1
Oct  9 13:46:02 e521 kern.err kernel: [10715.986028] sd 4:0:0:0: [sdb] Assuming drive cache: write through
Oct  9 13:46:02 e521 kern.notice kernel: [10715.986035] sd 4:0:0:0: [sdb] Attached SCSI removable disk

Re: [gentoo-dev] Suggestion for getting rid of udev

[Zac Medico]

On 10/11/2011 09:40 PM, Walter Dnes wrote:
> Hi all
> 
>   Recently, there was a firestorm on the gentoo-user list over the idea
> that udev would eventually require /usr to be on the same physical
> parition as /, or else use initramfs, which is its own can of worms. I'm
> not a programmer, let alone a developer.  Rather than merely ranting, I
> went and searched for an alternative.

Are you aware of the simple linuxrc approach that I suggested here?

http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml

-- 
Thanks,
Zac

Re: [gentoo-dev] Suggestion for getting rid of udev

[Walter Dnes]

On Tue, Oct 11, 2011 at 10:05:15PM -0700, Zac Medico wrote

> Are you aware of the simple linuxrc approach that I suggested here?
> 
> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml

  Thanks for the pointer.  I've got a spare box kicking around that I'll
try this on.  I really do want it to work.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Suggestion for getting rid of udev

[Nathan Phillip Brink]

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

On Wed, Oct 12, 2011 at 12:40:23AM -0400, Walter Dnes wrote:
> Hi all
> 
>   Recently, there was a firestorm on the gentoo-user list over the idea
> that udev would eventually require /usr to be on the same physical
> parition as /, or else use initramfs, which is its own can of worms. I'm
> not a programmer, let alone a developer.  Rather than merely ranting, I
> went and searched for an alternative.
...
> 
>   Another option is to take the current Gentoo setup, drop udev and
> use mdev in the same manner as Alpine uses it.  In case anyone asks,
> auto mounting should still be possible.  Attached is an excerpt from
> /var/log/messages from a basic Alpine install.  The kernel messages were
> generated when I inserted a USB key into a usb jack.

Seeing from the prior conversations here (sorry for lack of citation)
and
http://lists.busybox.net/pipermail/busybox/2011-September/076710.html
, I suspect that the root problem isn't with udev itself but with the
udev rules.

The magic which makes automatic userspace configuration possible is in
the udev rules and makes udev appear to be the problem. For example,
if you switch to mdev currently, you will notice that X11's device
autodetection doesn't work so well. (At least for me, X11's
autodetection magically works for detecting input devices with udev
but not with mdev). It is concievable that you could develop a
parallel database of mdev-compatible rules and even let packages
install rules specific to themselves (with modification to mdev
http://lists.busybox.net/pipermail/busybox/2011-September/076666.html
). With these sorts of things, you might figure out a way to make
X11's device autoconfiguration work or perform other device
initialization tasks. But at the same time, you have a good chance of
accidentally introducing a reliance on libraries/programs installed to
/usr. This latter problem is the issue, deciding how much software
should have --prefix=/ versus the normal --prefix=/usr.

You can already try out what using mdev instead of udev is like in
Gentoo. Just add `sys-apps/busybox mdev' to /etc/portage/package.use,
remerge busybox. You must be sure to be using busybox-1.92.2 or later
for bug #83301.

# rc-update add mdev sysinit
# rc-update del udev sysinit

But be 'ware that this isn't guaranteed to provide a successful boot
;-).

> Oct  9 13:46:00 e521 kern.info kernel: [10714.105621] usb 2-8: new high speed USB device using ehci_hcd and address 4
> Oct  9 13:46:00 e521 kern.info kernel: [10714.241353] usb 2-8: New USB device found, idVendor=13fe, idProduct=1e00
> Oct  9 13:46:00 e521 kern.info kernel: [10714.241357] usb 2-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> Oct  9 13:46:00 e521 kern.info kernel: [10714.241360] usb 2-8: Product: Patriot Memory  
> Oct  9 13:46:00 e521 kern.info kernel: [10714.241362] usb 2-8: Manufacturer:         
> Oct  9 13:46:00 e521 kern.info kernel: [10714.241364] usb 2-8: SerialNumber: 078215A302CF
> Oct  9 13:46:00 e521 kern.info kernel: [10714.244241] scsi4 : usb-storage 2-8:1.0
> Oct  9 13:46:01 e521 kern.notice kernel: [10715.279753] scsi 4:0:0:0: Direct-Access              Patriot Memory   PMAP PQ: 0 ANSI: 0 CCS
> Oct  9 13:46:02 e521 kern.notice kernel: [10715.930991] sd 4:0:0:0: [sdb] 31326208 512-byte logical blocks: (16.0 GB/14.9 GiB)
> Oct  9 13:46:02 e521 kern.notice kernel: [10715.931980] sd 4:0:0:0: [sdb] Write Protect is off
> Oct  9 13:46:02 e521 kern.debug kernel: [10715.931983] sd 4:0:0:0: [sdb] Mode Sense: 23 00 00 00
> Oct  9 13:46:02 e521 kern.err kernel: [10715.931986] sd 4:0:0:0: [sdb] Assuming drive cache: write through
> Oct  9 13:46:02 e521 kern.err kernel: [10715.935986] sd 4:0:0:0: [sdb] Assuming drive cache: write through
> Oct  9 13:46:02 e521 kern.info kernel: [10715.981381]  sdb: sdb1
> Oct  9 13:46:02 e521 kern.err kernel: [10715.986028] sd 4:0:0:0: [sdb] Assuming drive cache: write through
> Oct  9 13:46:02 e521 kern.notice kernel: [10715.986035] sd 4:0:0:0: [sdb] Attached SCSI removable disk

Unless if I'm missing something, those messages _always_ show up even
if udev or mdev haven't been invoked.

-- 
binki

Look out for missing or extraneous apostrophes!

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

Re: [gentoo-dev] Suggestion for getting rid of udev

[Walter Dnes]

On Wed, Oct 12, 2011 at 05:32:05AM +0000, Nathan Phillip Brink wrote

> You can already try out what using mdev instead of udev is like in
> Gentoo. Just add `sys-apps/busybox mdev' to /etc/portage/package.use,
> remerge busybox. You must be sure to be using busybox-1.92.2 or later
> for bug #83301.

  Did you mean busybox-1.19.2?  That's the latest ebuild in
/usr/portage, and it's still ~amd64 (~everything for that matter).

> # rc-update add mdev sysinit
> # rc-update del udev sysinit
> 
> But be 'ware that this isn't guaranteed to provide a successful boot
> ;-).

  Thanks for the idea.  I have a spare box kicking around that I can try
it on.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Suggestion for getting rid of udev

[Nathan Phillip Brink]

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

On Wed, Oct 12, 2011 at 09:09:24AM -0400, Walter Dnes wrote:
> On Wed, Oct 12, 2011 at 05:32:05AM +0000, Nathan Phillip Brink wrote
> 
> > You can already try out what using mdev instead of udev is like in
> > Gentoo. Just add `sys-apps/busybox mdev' to /etc/portage/package.use,
> > remerge busybox. You must be sure to be using busybox-1.92.2 or later
> > for bug #83301.
> 
>   Did you mean busybox-1.19.2?  That's the latest ebuild in
> /usr/portage, and it's still ~amd64 (~everything for that matter).

Yes, Oops.

-- 
binki

Look out for missing or extraneous apostrophes!

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

Re: [gentoo-dev] Suggestion for getting rid of udev

[Michał Górny]

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

On Wed, 12 Oct 2011 00:40:23 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

>   The other option is to drop udev entirely.  As an example, I suggest
> looking at Alpine Linux http://alpinelinux.org/  It's a lightweight
> server-oriented distro.  It uses busybox's mdev instead of udev, and
> some other mdev substitutes in place of standard packages.  It uses
> openrc.  Furthermore, "previous versions of Alpine were based on
> Gentoo" as per
> http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package so there
> should be no problem with us borrowing back from Alpine.

Goodbye desktop users then.

We recently dropped HAL. Now all the magic that was done by HAL (and
required udev anyway) is done through udev directly. Dropping udev =
dropping it all. This means that no *kit would work anymore, xorg will
require explicit configuration, bluez may not work anymore as well.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Suggestion for getting rid of udev

[Walter Dnes]

> Goodbye desktop users then.
> 
> We recently dropped HAL. Now all the magic that was done by HAL (and
> required udev anyway) is done through udev directly.

  My system worked just fine before HAL was introduced, thank you.  I
always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask
and my system continued to work just fine, thank you.  Given the great
HAL fiasco, the fact that HAL has been incorporated into udev is yet one
more reason for dropping udev <G>.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Suggestion for getting rid of udev

[Canek Peláez Valdés]

On Wed, Oct 12, 2011 at 6:09 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>> Goodbye desktop users then.
>>
>> We recently dropped HAL. Now all the magic that was done by HAL (and
>> required udev anyway) is done through udev directly.
>
>  My system worked just fine before HAL was introduced, thank you.  I
> always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask
> and my system continued to work just fine, thank you.

This is not about *your* system, it's about the general Gentoo
community systems. And in most cases, the functionality that mdev
provides is not even a fraction of what udev can do, like it or not.

I have a pair of bluetooth headphones; I turn them up and set them to
pair with something, and gnome-shell in GNOME 3 right away asks me if
it's OK to pair with them. I say yes, and the headphones are
immediately available in the desktop; thanks to PulseAudio, I can
transfer all my apps (or only some of them) to the headphones, without
even needing to pause the streams.

All of this without a single modification to a config file. It just
works. And that is thanks to udev (among several other pieces of the
stack).

mdev is designed for embedded systems (like busybox). By design it
cannot handle of the cases that udev handles, and so it is not suited
for a general purpose distribution like Gentoo. If you wan to try to
use it, that's your right of course. But don't ask the Gentoo devs to
do the work for you; do it yourself. And be aware that anyway the devs
will choose to stick with udev (like many have already said), because
they have to think about the general case, not an arbitrary particular
case.

Just the .02 ${CURRENCY} from an old Gentoo user happy with systemd,
dracut, udev, dbus, GNOME 3, and other really cool new technologies.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Suggestion for getting rid of udev

[Michał Górny]

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

On Wed, 12 Oct 2011 09:09:49 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> > Goodbye desktop users then.
> > 
> > We recently dropped HAL. Now all the magic that was done by HAL (and
> > required udev anyway) is done through udev directly.
> 
>   My system worked just fine before HAL was introduced, thank you.  I
> always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask
> and my system continued to work just fine, thank you.  Given the great
> HAL fiasco, the fact that HAL has been incorporated into udev is yet
> one more reason for dropping udev <G>.

Thanks for your insight on the topic.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Suggestion for getting rid of udev

[Nirbheek Chauhan]

On Wed, Oct 12, 2011 at 6:39 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>> Goodbye desktop users then.
>>
>> We recently dropped HAL. Now all the magic that was done by HAL (and
>> required udev anyway) is done through udev directly.
>
>  My system worked just fine before HAL was introduced, thank you.  I
> always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask
> and my system continued to work just fine, thank you.  Given the great
> HAL fiasco, the fact that HAL has been incorporated into udev is yet one
> more reason for dropping udev <G>.
>

Then please continue with udev in package.mask and kindly stop trying
to impose your workflow on the rest of the world.

This thread is a waste of time.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Suggestion for getting rid of udev

[Ciaran McCreesh]

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

On Wed, 12 Oct 2011 23:00:23 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> Then please continue with udev in package.mask and kindly stop trying
> to impose your workflow on the rest of the world.

Isn't the point here that the desktop / GNOME OS guys are trying to
impose their deep integration, tight coupling workflow upon the rest of
the world?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Suggestion for getting rid of udev

[Rich Freeman]

On Wed, Oct 12, 2011 at 1:49 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Wed, 12 Oct 2011 23:00:23 +0530
> Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
>> Then please continue with udev in package.mask and kindly stop trying
>> to impose your workflow on the rest of the world.
>
> Isn't the point here that the desktop / GNOME OS guys are trying to
> impose their deep integration, tight coupling workflow upon the rest of
> the world?

So, Gentoo is about choice and empowering the user, so I think that if
somebody wants to offer patches that allow mdev to work better without
adversely affecting udev use then I'd encourage devs to accept those
patches.

However, if Gentoo aims to make Gnome/KDE difficult to deploy with the
default configuration we'll be shooting ourselves in the feet.  I
think a lot more people run KDE/Gnome on Gentoo than run Gentoo with
/usr not on root but who are unwilling to run an initramfs.

Rich

Re: [gentoo-dev] Suggestion for getting rid of udev

[Olivier Crête]

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

On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote:
> On Wed, 12 Oct 2011 23:00:23 +0530
> Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> > Then please continue with udev in package.mask and kindly stop trying
> > to impose your workflow on the rest of the world.
> 
> Isn't the point here that the desktop / GNOME OS guys are trying to
> impose their deep integration, tight coupling workflow upon the rest of
> the world?

We're imposing our deep integration because it's the only way to make a
compelling platform that "just works", forcing users to tell the
computer something the computer already knows is just plain lazy and
stupid.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

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

Re: [gentoo-dev] Suggestion for getting rid of udev

[Rich Freeman]

2011/10/13 Olivier Crête <tester@gentoo.org>:
> We're imposing our deep integration because it's the only way to make a
> compelling platform that "just works", forcing users to tell the
> computer something the computer already knows is just plain lazy and
> stupid.

I'd also look at it another way.  It is a lot easier to take a
well-integrated platform and chop out the parts that you don't need,
than to take a million pieces and build yourself an integrated
platform.

I think the key is to still define boundaries between the layers and
interfaces such that you still can chop out parts.  I think that there
is a danger that we may get to a point where that becomes increasingly
difficult.  If KDE and Gnome were to come out with separate
incompatible implementations of SysVInit, XDM, X11, and automounting
then having both on the same system would no longer be a matter of
just picking a session in the XDM interface.

However, the vertical integration right now isn't that bad.  We can
deploy udev/dbus/etc and people who don't need it can just remove it
without much fuss.

Rich

Re: [gentoo-dev] Suggestion for getting rid of udev

[Arun Raghavan]

On 13 October 2011 20:58, Rich Freeman <rich0@gentoo.org> wrote:
> 2011/10/13 Olivier Crête <tester@gentoo.org>:
>> We're imposing our deep integration because it's the only way to make a
>> compelling platform that "just works", forcing users to tell the
>> computer something the computer already knows is just plain lazy and
>> stupid.
>
> I'd also look at it another way.  It is a lot easier to take a
> well-integrated platform and chop out the parts that you don't need,
> than to take a million pieces and build yourself an integrated
> platform.

While it has been the way just about all platform development on Linux
has taken place, what this mode of thinking ignores is that
gratuitously supporting as many corner cases as you can means that you
need to support a combinatorial explosion of pieces, which so far has
only managed to keep our stack fragmented and an enormous pita to work
with.

I'm not saying we should narrow our focus too much, but every decision
to support weird ways of doing things has a cost, and if you're going
to support it, you (as an upstream developer) are spending time that
could possibly have been spent making the whole system better.

(that's to set some perspective on why things are heading the way they
are, and discussing whether this is sensible or not probably is going
to spin offtopic for gentoo-dev really quickly)

While I've seen a lot of whining about this whole issue, I certainly
haven't been seen any effort to actually solve the problem within the
existing framework. For example, if someone cares enough, why not
write a wrapper script to track down the programs and libraries at
runtime that actually do use /usr so it's easier to say "these
packages install rules that need / and /usr on the same partition".

-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] Suggestion for getting rid of udev

[Mike Frysinger]

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

On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
> While I've seen a lot of whining about this whole issue, I certainly
> haven't been seen any effort to actually solve the problem within the
> existing framework. For example, if someone cares enough, why not
> write a wrapper script to track down the programs and libraries at
> runtime that actually do use /usr so it's easier to say "these
> packages install rules that need / and /usr on the same partition".

(1) udev has provided a workaround of sorts for this already: udevadm trigger 
--type=failed.  this is the udev-postmount init.d script.  (2) it's fairly 
trivial to locate most (all?) the failing rules with a single grep: grep /usr 
-R /lib/udev/rules.d/.
-mike

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

Re: [gentoo-dev] Suggestion for getting rid of udev

[Samuli Suominen]

On 10/13/2011 08:02 PM, Mike Frysinger wrote:
> On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
>> While I've seen a lot of whining about this whole issue, I certainly
>> haven't been seen any effort to actually solve the problem within the
>> existing framework. For example, if someone cares enough, why not
>> write a wrapper script to track down the programs and libraries at
>> runtime that actually do use /usr so it's easier to say "these
>> packages install rules that need / and /usr on the same partition".
> 
> (1) udev has provided a workaround of sorts for this already: udevadm trigger 
> --type=failed.  this is the udev-postmount init.d script.  (2) it's fairly 
> trivial to locate most (all?) the failing rules with a single grep: grep /usr 
> -R /lib/udev/rules.d/.

nitpicking for (2): also /var, since that's used by alsa's udev rules
(alsactl stores info there to restore mixers for eg)

Re: [gentoo-dev] Suggestion for getting rid of udev

[Canek Peláez Valdés]

On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
>> While I've seen a lot of whining about this whole issue, I certainly
>> haven't been seen any effort to actually solve the problem within the
>> existing framework. For example, if someone cares enough, why not
>> write a wrapper script to track down the programs and libraries at
>> runtime that actually do use /usr so it's easier to say "these
>> packages install rules that need / and /usr on the same partition".
>
> (1) udev has provided a workaround of sorts for this already: udevadm trigger
> --type=failed.  this is the udev-postmount init.d script.  (2) it's fairly
> trivial to locate most (all?) the failing rules with a single grep: grep /usr
> -R /lib/udev/rules.d/.

If this comment is true (haven't looked at the code):

https://bugs.gentoo.org/show_bug.cgi?id=375263#c23

that trigger has been removed from udev.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Suggestion for getting rid of udev

[Canek Peláez Valdés]

On Thu, Oct 13, 2011 at 11:55 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
>>> While I've seen a lot of whining about this whole issue, I certainly
>>> haven't been seen any effort to actually solve the problem within the
>>> existing framework. For example, if someone cares enough, why not
>>> write a wrapper script to track down the programs and libraries at
>>> runtime that actually do use /usr so it's easier to say "these
>>> packages install rules that need / and /usr on the same partition".
>>
>> (1) udev has provided a workaround of sorts for this already: udevadm trigger
>> --type=failed.  this is the udev-postmount init.d script.  (2) it's fairly
>> trivial to locate most (all?) the failing rules with a single grep: grep /usr
>> -R /lib/udev/rules.d/.
>
> If this comment is true (haven't looked at the code):
>
> https://bugs.gentoo.org/show_bug.cgi?id=375263#c23
>
> that trigger has been removed from udev.

Answering myselef; it is gone:

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=289a1821a4a7636ce42a6c7adc3a9bb49421a5ea

commit 289a1821a4a7636ce42a6c7adc3a9bb49421a5ea
Author: Kay Sievers <kay.sievers@vrfy.org>
Date:   Thu Oct 6 00:45:06 2011 +0200

    remove 'udevadm trigger --type=failed' and SYSFS, ID, BUS keys

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Suggestion for getting rid of udev

[Mike Frysinger]

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

On Thursday 13 October 2011 14:55:45 Canek Peláez Valdés wrote:
> On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger wrote:
> > On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
> >> While I've seen a lot of whining about this whole issue, I certainly
> >> haven't been seen any effort to actually solve the problem within the
> >> existing framework. For example, if someone cares enough, why not
> >> write a wrapper script to track down the programs and libraries at
> >> runtime that actually do use /usr so it's easier to say "these
> >> packages install rules that need / and /usr on the same partition".
> > 
> > (1) udev has provided a workaround of sorts for this already: udevadm
> > trigger --type=failed.  this is the udev-postmount init.d script.  (2)
> > it's fairly trivial to locate most (all?) the failing rules with a
> > single grep: grep /usr -R /lib/udev/rules.d/.
> 
> If this comment is true (haven't looked at the code):
> 
> https://bugs.gentoo.org/show_bug.cgi?id=375263#c23
> 
> that trigger has been removed from udev.

... which is what spurred this entire debate in the first place
-mike

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

Re: [gentoo-dev] Suggestion for getting rid of udev

[Ciaran McCreesh]

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

On Thu, 13 Oct 2011 11:14:31 -0400
Olivier Crête <tester@gentoo.org> wrote:

> On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote:
> > On Wed, 12 Oct 2011 23:00:23 +0530
> > Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> > > Then please continue with udev in package.mask and kindly stop
> > > trying to impose your workflow on the rest of the world.
> > 
> > Isn't the point here that the desktop / GNOME OS guys are trying to
> > impose their deep integration, tight coupling workflow upon the
> > rest of the world?
> 
> We're imposing our deep integration because it's the only way to make
> a compelling platform that "just works", forcing users to tell the
> computer something the computer already knows is just plain lazy and
> stupid.

The problem with a platform that "just works" is that when it doesn't
work, no-one knows how to fix it. That's what's happened here: the deep
integration doesn't work in the common case that /usr is on its own
filesystem, but because of all the excessive coupling you're unable to
fix it and so are trying to pass the blame elsewhere.

The first step in fixing it is to decouple all of the horrible mess
that has been making its way into the base system over the past couple
of years.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Suggestion for getting rid of udev

[Michael Schreckenbauer]

Sorry for being completely OT now, will be the only mail on this from my 
side...

On Thursday, 13. October 2011 18:05:47 Ciaran McCreesh wrote:
> On Thu, 13 Oct 2011 11:14:31 -0400
> 
> Olivier Crête <tester@gentoo.org> wrote:
> > On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote:
> > > On Wed, 12 Oct 2011 23:00:23 +0530
> > > 
> > > Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> > > > Then please continue with udev in package.mask and kindly stop
> > > > trying to impose your workflow on the rest of the world.
> > > 
> > > Isn't the point here that the desktop / GNOME OS guys are trying to
> > > impose their deep integration, tight coupling workflow upon the
> > > rest of the world?
> > 
> > We're imposing our deep integration because it's the only way to make
> > a compelling platform that "just works", forcing users to tell the
> > computer something the computer already knows is just plain lazy and
> > stupid.
> 
> The problem with a platform that "just works" is that when it doesn't
> work, no-one knows how to fix it. That's what's happened here: the deep
> integration doesn't work in the common case that /usr is on its own
> filesystem, but because of all the excessive coupling you're unable to
> fix it and so are trying to pass the blame elsewhere.
> 
> The first step in fixing it is to decouple all of the horrible mess
> that has been making its way into the base system over the past couple
> of years.

in what way will exherbo deal wih this mess? Are there any plans?
Feel free to mail me privately and/or answer this on the user-ML, I think some 
of us are quite interested.

Thanks,
Michael

Re: [gentoo-dev] Suggestion for getting rid of udev

[Wulf C. Krueger]

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

On 15.10.2011 10:42, Michael Schreckenbauer wrote:
> in what way will exherbo deal wih this mess? Are there any plans?

We don't support /usr on a separate partition. People can, of course, do
that and I'll point them to dracut for creating an initramfs.

Or they can do whatever works for them. People using Exherbo are
expected to be able to deal with such stuff.

Best regards, Wulf


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

Re: [gentoo-dev] Suggestion for getting rid of udev

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 1:57 AM, Wulf C. Krueger <wk@mailstation.de> wrote:
> On 15.10.2011 10:42, Michael Schreckenbauer wrote:
>> in what way will exherbo deal wih this mess? Are there any plans?
>
> We don't support /usr on a separate partition. People can, of course, do
> that and I'll point them to dracut for creating an initramfs.
>
> Or they can do whatever works for them. People using Exherbo are
> expected to be able to deal with such stuff.

And I believe exherbo recommends systemd as init system.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Suggestion for getting rid of udev

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 2:13 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sat, Oct 15, 2011 at 1:57 AM, Wulf C. Krueger <wk@mailstation.de> wrote:
>> On 15.10.2011 10:42, Michael Schreckenbauer wrote:
>>> in what way will exherbo deal wih this mess? Are there any plans?
>>
>> We don't support /usr on a separate partition. People can, of course, do
>> that and I'll point them to dracut for creating an initramfs.
>>
>> Or they can do whatever works for them. People using Exherbo are
>> expected to be able to deal with such stuff.
>
> And I believe exherbo recommends systemd as init system.

Yes, they do:

http://exherbo.org/docs/install-guide.html

o Install an init system

     There’s no init system in our stages. This allows you to choose
whatever init system (or none) you’d like to use:

       - sys-apps/systemd (recommended) - modern, fast init system.
Needs kernel >=2.6.36-rc1.
       - sys-apps/baselayout - Gentoo’s old, crufty Baselayout-1.
       - sys-apps/upstart - Ubuntu’s init system. We don’t generally
supply init scripts for this.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Suggestion for getting rid of udev

[Zac Medico]

On 10/15/2011 01:57 AM, Wulf C. Krueger wrote:
> On 15.10.2011 10:42, Michael Schreckenbauer wrote:
>> in what way will exherbo deal wih this mess? Are there any plans?
> 
> We don't support /usr on a separate partition. People can, of course, do
> that and I'll point them to dracut for creating an initramfs.
> 
> Or they can do whatever works for them. People using Exherbo are
> expected to be able to deal with such stuff.

I don't think it's a good idea for Gentoo to encourage users to have
/usr on a separate partition. We should probably remove the separate
/usr partition from "Code Listing 2.1: Filesystem usage example" in our
handbook:

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=4#doc_chap2_pre1

-- 
Thanks,
Zac

Re: [gentoo-dev] supporting /usr on separate partition (was: Suggestion for getting rid of udev)

[Ian Stakenvicius]

On 15/10/11 06:07 PM, Zac Medico wrote:
> On 10/15/2011 01:57 AM, Wulf C. Krueger wrote:
>> On 15.10.2011 10:42, Michael Schreckenbauer wrote:
>>> in what way will exherbo deal wih this mess? Are there any plans?
>>
>> We don't support /usr on a separate partition. People can, of course, do
>> that and I'll point them to dracut for creating an initramfs.
>>
>> Or they can do whatever works for them. People using Exherbo are
>> expected to be able to deal with such stuff.
> 
> I don't think it's a good idea for Gentoo to encourage users to have
> /usr on a separate partition. We should probably remove the separate
> /usr partition from "Code Listing 2.1: Filesystem usage example" in our
> handbook:
> 
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=4#doc_chap2_pre1
> 

For desktops i've never seen much purpose of having /usr on its own
partition (or more than the usual 3 of /boot,/,swap tbh), but for
servers I have seen a lot of configurations over the years that put /usr
on its own partition.  Exherbo aside, I would expect that Gentoo would
(continue to?) support doing this.

As per the documentation itself, Code Listing 2.1 is i believe an
example of what is possible, not what we are encouraging users to do.
That doc seems pretty clear that the default is partitioning scheme is
the default /boot,/,swap ...

And just to confirm, doesn't udev's installation (which is primarily in
/lib) support /usr on a separate partition now, without an initramfs?

Re: [gentoo-dev] supporting /usr on separate partition

[Zac Medico]

On 10/16/2011 05:52 AM, Ian Stakenvicius wrote:
> On 15/10/11 06:07 PM, Zac Medico wrote:
>> On 10/15/2011 01:57 AM, Wulf C. Krueger wrote:
>>> On 15.10.2011 10:42, Michael Schreckenbauer wrote:
>>>> in what way will exherbo deal wih this mess? Are there any plans?
>>>
>>> We don't support /usr on a separate partition. People can, of course, do
>>> that and I'll point them to dracut for creating an initramfs.
>>>
>>> Or they can do whatever works for them. People using Exherbo are
>>> expected to be able to deal with such stuff.
>>
>> I don't think it's a good idea for Gentoo to encourage users to have
>> /usr on a separate partition. We should probably remove the separate
>> /usr partition from "Code Listing 2.1: Filesystem usage example" in our
>> handbook:
>>
>> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=4#doc_chap2_pre1
>>
> 
> For desktops i've never seen much purpose of having /usr on its own
> partition (or more than the usual 3 of /boot,/,swap tbh), but for
> servers I have seen a lot of configurations over the years that put /usr
> on its own partition.  Exherbo aside, I would expect that Gentoo would
> (continue to?) support doing this.

Well, you'll have to define the meaning of "support" in this context. I
simply said that it shouldn't be encouraged, with me reason being that
it tends to add unnecessary complexity (in violation of the KISS
principle [1]).

> As per the documentation itself, Code Listing 2.1 is i believe an
> example of what is possible, not what we are encouraging users to do.
> That doc seems pretty clear that the default is partitioning scheme is
> the default /boot,/,swap ...

Why should our main installation docs mention a configuration that the
vast majority of our users (all?) would be better off without?

> And just to confirm, doesn't udev's installation (which is primarily in
> /lib) support /usr on a separate partition now, without an initramfs?

What's the benefit of having /usr on a separate partition anyway? The
only somewhat reasonable explanation that I've heard is so that it can
be mounted readonly. If people want that, I think it's perfectly
reasonable to expect them to use either an initramfs or a simple linuxrc
approach [2] to ensure that /usr is mounted before init starts. For
complex configurations like this, we can have a separate page of docs,
like the raid+lvm2 page [3], and link it from the main installation docs
if we want.

[1] http://en.wikipedia.org/wiki/KISS_principle
[2]
http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml
[3] http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml
-- 
Thanks,
Zac

Re: [gentoo-dev] supporting /usr on separate partition

[Graham Murray]

Zac Medico <zmedico@gentoo.org> writes:

> What's the benefit of having /usr on a separate partition anyway? The
> only somewhat reasonable explanation that I've heard is so that it can
> be mounted readonly. 

One benefit, especially in a large server 'farm' is that several servers
can share the same /usr by NFS mounting, read-only, the same partition
on all of the servers. This both ensures that all the servers are kept
in-step and greatly simplifies the upgrade process.

Re: [gentoo-dev] supporting /usr on separate partition

[Michał Górny]

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

On Sun, 16 Oct 2011 20:36:23 +0100
Graham Murray <graham@gmurray.org.uk> wrote:

> Zac Medico <zmedico@gentoo.org> writes:
> 
> > What's the benefit of having /usr on a separate partition anyway?
> > The only somewhat reasonable explanation that I've heard is so that
> > it can be mounted readonly. 
> 
> One benefit, especially in a large server 'farm' is that several
> servers can share the same /usr by NFS mounting, read-only, the same
> partition on all of the servers. This both ensures that all the
> servers are kept in-step and greatly simplifies the upgrade process.

Unless upgrade involves files being outside of /usr.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] supporting /usr on separate partition

[Ian Stakenvicius]

Splitting this up since i'm kind of starting two threads here..

----- Documentation discussion -----
On 16/10/11 02:44 PM, Zac Medico wrote:
> 
> Well, you'll have to define the meaning of "support" in this context. I
> simply said that it shouldn't be encouraged, with me reason being that
> it tends to add unnecessary complexity (in violation of the KISS
> principle [1]).
> 

I would agree with this (that it shouldn't be encouraged), but I don't
think the Handbook is encouraging it now, as it is written..


>> As per the documentation itself, Code Listing 2.1 is i believe an
>> example of what is possible, not what we are encouraging users to do.
>> That doc seems pretty clear that the default is partitioning scheme is
>> the default /boot,/,swap ...
> 
> Why should our main installation docs mention a configuration that the
> vast majority of our users (all?) would be better off without?
> 

You'd have to talk to the original authors to confirm but I believe this
would be to illustrate the possibilities and give users info that will
let them think about their partitioning scheme, instead of telling them
what to do.  Essentially, to introduce and educate about partitions and
filesystems.

(it is the Gentoo Handbook, not the Gentoo Quick Install Howto, after all)


> What's the benefit of having /usr on a separate partition anyway? 

I think that's covered rather generically in the guide -- different fs
type, won't run out of space on / if /usr fills up, different mount
options (ie, mounting ROOT ro and /usr rw); and of course if /usr is on
separate physical media (ie, a nice big RAID, while / is on, say, a
small SSD).


----- Support/implementation discussion -----

> ... If people want that, I think it's perfectly
> reasonable to expect them to use either an initramfs or a simple linuxrc
> approach [2] to ensure that /usr is mounted before init starts. 

...this would make sense, although in terms of "support" i think it
would be appropriate that we would provide this linuxrc wrapper on any
init system that needs /usr mounted.

Re: [gentoo-dev] supporting /usr on separate partition

[Zac Medico]

On 10/17/2011 09:02 AM, Ian Stakenvicius wrote:
> Splitting this up since i'm kind of starting two threads here..
> 
> ----- Documentation discussion -----
> On 16/10/11 02:44 PM, Zac Medico wrote:
>>
>> Well, you'll have to define the meaning of "support" in this context. I
>> simply said that it shouldn't be encouraged, with me reason being that
>> it tends to add unnecessary complexity (in violation of the KISS
>> principle [1]).
>>
> 
> I would agree with this (that it shouldn't be encouraged), but I don't
> think the Handbook is encouraging it now, as it is written..

It depends on how you define "encouraging" in this context. The fact
that /usr is shown as a separate partition might be considered
"suggestive" if not "encouraging". If a user takes that suggestion
without knowing the consequences (special initramfs or linuxrc init
wrapper configuration), then then it could cause some disappointment
when they finally discover the consequences.

> ----- Support/implementation discussion -----
> 
>> ... If people want that, I think it's perfectly
>> reasonable to expect them to use either an initramfs or a simple linuxrc
>> approach [2] to ensure that /usr is mounted before init starts. 
> 
> ...this would make sense, although in terms of "support" i think it
> would be appropriate that we would provide this linuxrc wrapper on any
> init system that needs /usr mounted.

If someone wants to take on the burden of maintaining an init wrapper
like that, then I guess that's fine. However, I wouldn't consider it to
be an absolute requirement. I think it would be fine (maybe preferable)
to simply provide a doc that describes how to mount /usr via an
initramfs or linuxrc init wrapper. Such a doc would only be needed by
those users who require that /usr be on a separate partition.
-- 
Thanks,
Zac

Re: [gentoo-dev] supporting /usr on separate partition

[Ian Stakenvicius]

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

...and recombining again..

On 2011-10-17, at 1:24 PM, Zac Medico <zmedico@gentoo.org> wrote:

> On 10/17/2011 09:02 AM, Ian Stakenvicius wrote:
>> Splitting this up since i'm kind of starting two threads here..
>> 
>> ----- Documentation discussion -----
>> On 16/10/11 02:44 PM, Zac Medico wrote:
>>> 
>>> Well, you'll have to define the meaning of "support" in this context. I
>>> simply said that it shouldn't be encouraged, with me reason being that
>>> it tends to add unnecessary complexity (in violation of the KISS
>>> principle [1]).
>>> 
>> 
>> I would agree with this (that it shouldn't be encouraged), but I don't
>> think the Handbook is encouraging it now, as it is written..
> 
> It depends on how you define "encouraging" in this context. The fact
> that /usr is shown as a separate partition might be considered
> "suggestive" if not "encouraging". If a user takes that suggestion
> without knowing the consequences (special initramfs or linuxrc init
> wrapper configuration), then then it could cause some disappointment
> when they finally discover the consequences.
> 
>> ----- Support/implementation discussion -----
>> 
>>> ... If people want that, I think it's perfectly
>>> reasonable to expect them to use either an initramfs or a simple linuxrc
>>> approach [2] to ensure that /usr is mounted before init starts. 
>> 
>> ...this would make sense, although in terms of "support" i think it
>> would be appropriate that we would provide this linuxrc wrapper on any
>> init system that needs /usr mounted.
> 
> If someone wants to take on the burden of maintaining an init wrapper
> like that, then I guess that's fine. However, I wouldn't consider it to
> be an absolute requirement. I think it would be fine (maybe preferable)
> to simply provide a doc that describes how to mount /usr via an
> initramfs or linuxrc init wrapper. Such a doc would only be needed by
> those users who require that /usr be on a separate partition.

This makes sense.  So the Handbook could be updated with a caveat after the large partition example to say something like "/usr on it's own partition needs special consideration, please see XXXXX" ... this works.

[-- Attachment #2: Type: text/html, Size: 4122 bytes --]

Re: [gentoo-dev] supporting /usr on separate partition

[Samuli Suominen]

On 10/17/2011 08:50 PM, Ian Stakenvicius wrote:

please disable HTML in your mail client.

Re: [gentoo-dev] supporting /usr on separate partition

[Ian Stakenvicius]

On 17/10/11 01:55 PM, Samuli Suominen wrote:
> On 10/17/2011 08:50 PM, Ian Stakenvicius wrote:
> 
> please disable HTML in your mail client.
> 


CRAP. sorry all.  will stop emailing from my phone.

Re: [gentoo-dev] supporting /usr on separate partition

[Sven Vermeulen]

On Mon, Oct 17, 2011 at 01:50:04PM -0400, Ian Stakenvicius wrote:
> > If someone wants to take on the burden of maintaining an init wrapper
> > like that, then I guess that's fine. However, I wouldn't consider it to
> > be an absolute requirement. I think it would be fine (maybe preferable)
> > to simply provide a doc that describes how to mount /usr via an
> > initramfs or linuxrc init wrapper. Such a doc would only be needed by
> > those users who require that /usr be on a separate partition.
> 
> This makes sense.  So the Handbook could be updated with a caveat after 
> the large partition example to say something like "/usr on it's own
> partition needs special consideration, please see XXXXX" ... this$
> works.

(Ian, it's a general reply, not specific to your e-mail)

I've updated the Gentoo Handbook just a few moments ago to mention something
like this in the introduction of the partition section "How Many and How
Big":

--Snippet from the commit result:
  <p>
  However, multiple partitions have disadvantages as well. If not configured
  properly, you will have a system with lots of free space on one partition
  and none on another. Another nuisance is that separate partitions - especially
  for important mountpoints like <path>/usr</path> or <path>/var</path> -
  often require the administrator to boot with an initramfs to mount the partition
  before other boot scripts start. This isn't always the case though, so YMMV.
  </p>
  
  <p>
  There is also a 15-partition limit for SCSI and SATA unless you use GPT
  labels.
  </p>
--End Snippet

Now, I must say I find it strange that people think that the Gentoo Handbook
suggests users to use a separate /usr partition. It does not. The default
partitioning that we use is a separate /boot (yes, this can and has been
debated in the past, I'm not going to change this) and / with a separate
swap partition. Nothing more, nothing less. There are a few code listings
where an example output is given which holds a separate /usr but I hope all
those listings are clear that they are examples.

It also states that this is an example we use in the Gentoo Handbook and
that it depends on the user how he wants his partition scheme layed out.

I'm hoping that the above update clarifies this sufficiently so that huge
threads like this one don't need to reappear again ;-) If you think it is
still unclear or needs improvements left or right, don't hesitate to mail me
or, even better, file a bugreport (I act better on bug reports than on
e-mails).

Oh, and I use a separate /usr with no initramfs (yet), with software raid 
and lvm2. 

/me quickly hides

Wkr,
	Sven Vermeulen

Re: [gentoo-dev] supporting /usr on separate partition

[Zac Medico]

On 10/17/2011 01:01 PM, Sven Vermeulen wrote:
> --Snippet from the commit result:
>   <p>
>   However, multiple partitions have disadvantages as well. If not configured
>   properly, you will have a system with lots of free space on one partition
>   and none on another. Another nuisance is that separate partitions - especially
>   for important mountpoints like <path>/usr</path> or <path>/var</path> -
>   often require the administrator to boot with an initramfs to mount the partition
>   before other boot scripts start. This isn't always the case though, so YMMV.
>   </p>
>   
>   <p>
>   There is also a 15-partition limit for SCSI and SATA unless you use GPT
>   labels.
>   </p>
> --End Snippet
> 
> Now, I must say I find it strange that people think that the Gentoo Handbook
> suggests users to use a separate /usr partition. It does not. The default
> partitioning that we use is a separate /boot (yes, this can and has been
> debated in the past, I'm not going to change this) and / with a separate
> swap partition. Nothing more, nothing less. There are a few code listings
> where an example output is given which holds a separate /usr but I hope all
> those listings are clear that they are examples.

Even if you don't consider them to be formal "suggestions", their mere
presence as examples lends them credence.

> It also states that this is an example we use in the Gentoo Handbook and
> that it depends on the user how he wants his partition scheme layed out.
> 
> I'm hoping that the above update clarifies this sufficiently so that huge
> threads like this one don't need to reappear again ;-) If you think it is
> still unclear or needs improvements left or right, don't hesitate to mail me
> or, even better, file a bugreport (I act better on bug reports than on
> e-mails).

I think the new "disadvantages" section that you posted should convey an
appropriate level of caution. Thanks!
-- 
Thanks,
Zac

Re: [gentoo-dev] Suggestion for getting rid of udev

[Rich Freeman]

On Sat, Oct 15, 2011 at 6:07 PM, Zac Medico <zmedico@gentoo.org> wrote:
>
> I don't think it's a good idea for Gentoo to encourage users to have
> /usr on a separate partition. We should probably remove the separate
> /usr partition from "Code Listing 2.1: Filesystem usage example" in our
> handbook:
>
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=4#doc_chap2_pre1
>

Well, if we want to do that then we should also update:
http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml

Of course - that is an initramfs-less configuration, and such a thing
would be nearly impossible to do with /usr on root unless you
basically don't put anything of value on the LVM volumes in the first
place.  You could put everything but /boot on LVM and then use an
initramfs.  Or, you need to cover mounting /usr, /var, etc from the
initramfs.

And I don't think it is a good idea to NOT have a supported RAID/LVM
configuration.  That is hardly an edge case...

Rich

Re: [gentoo-dev] Suggestion for getting rid of udev

[Zac Medico]

On 10/16/2011 06:07 AM, Rich Freeman wrote:
> On Sat, Oct 15, 2011 at 6:07 PM, Zac Medico <zmedico@gentoo.org> wrote:
>>
>> I don't think it's a good idea for Gentoo to encourage users to have
>> /usr on a separate partition. We should probably remove the separate
>> /usr partition from "Code Listing 2.1: Filesystem usage example" in our
>> handbook:
>>
>> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=4#doc_chap2_pre1
>>
> 
> Well, if we want to do that then we should also update:
> http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml
> 
> Of course - that is an initramfs-less configuration, and such a thing
> would be nearly impossible to do with /usr on root unless you
> basically don't put anything of value on the LVM volumes in the first
> place.  You could put everything but /boot on LVM and then use an
> initramfs.  Or, you need to cover mounting /usr, /var, etc from the
> initramfs.
> 
> And I don't think it is a good idea to NOT have a supported RAID/LVM
> configuration.  That is hardly an edge case...

If those LVM volumes require userspace tools to mount, then I think it's
perfectly reasonable to expect them to use either an initramfs or a
simple linuxrc approach [1] to ensure that /usr is mounted before init
starts.

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

Re: [gentoo-dev] Suggestion for getting rid of udev

[Joost Roeleveld]

On Sunday, October 16, 2011 12:33:51 PM Zac Medico wrote:
> On 10/16/2011 06:07 AM, Rich Freeman wrote:
> > On Sat, Oct 15, 2011 at 6:07 PM, Zac Medico <zmedico@gentoo.org> wrote:
> >> I don't think it's a good idea for Gentoo to encourage users to have
> >> /usr on a separate partition. We should probably remove the separate
> >> /usr partition from "Code Listing 2.1: Filesystem usage example" in
> >> our
> >> handbook:
> >> 
> >> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=4#d
> >> oc_chap2_pre1> 
> > Well, if we want to do that then we should also update:
> > http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml
> > 
> > Of course - that is an initramfs-less configuration, and such a thing
> > would be nearly impossible to do with /usr on root unless you
> > basically don't put anything of value on the LVM volumes in the first
> > place.  You could put everything but /boot on LVM and then use an
> > initramfs.  Or, you need to cover mounting /usr, /var, etc from the
> > initramfs.
> > 
> > And I don't think it is a good idea to NOT have a supported RAID/LVM
> > configuration.  That is hardly an edge case...
> 
> If those LVM volumes require userspace tools to mount, then I think it's
> perfectly reasonable to expect them to use either an initramfs or a
> simple linuxrc approach [1] to ensure that /usr is mounted before init
> starts.
> 
> [1]
> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.x
> ml

If this approach works, would it be an option to add this to the LVM [1] and 
RAID+LVM [2] pages?

[1]
http://www.gentoo.org/doc/en/lvm2.xml

[2]
http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml

--
Joost

Re: [gentoo-dev] Suggestion for getting rid of udev

[Zac Medico]

On 10/17/2011 01:59 PM, Joost Roeleveld wrote:
> On Sunday, October 16, 2011 12:33:51 PM Zac Medico wrote:
>> If those LVM volumes require userspace tools to mount, then I think it's
>> perfectly reasonable to expect them to use either an initramfs or a
>> simple linuxrc approach [1] to ensure that /usr is mounted before init
>> starts.
>>
>> [1]
>> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml
> 
> If this approach works, would it be an option to add this to the LVM [1] and 
> RAID+LVM [2] pages?

You can use a linuxrc instead of an initramfs as long as your root
filesystem can be mounted automatically via kernel parameters, and that
root filesystem contains the necessary userspace tools (like busybox and
lvm) to mount everthing else that's required to be mounted before init
starts.

> [1]
> http://www.gentoo.org/doc/en/lvm2.xml
> 
> [2]
> http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml
-- 
Thanks,
Zac

Re: [gentoo-dev] Suggestion for getting rid of udev

[Walter Dnes]

On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote

> We're imposing our deep integration because it's the only way to make a
> compelling platform that "just works", forcing users to tell the
> computer something the computer already knows is just plain lazy and
> stupid.

  Eventually, that hits Mac or Windows-like levels of dictating 1 or 2
sets of choices and nothing else.  If I wanted Mac or Windows, I'd be
running Mac or Windows.  If the developers don't deliberately make my
system break if /usr and /var aren't physically on / (and no initramfs),
I'm willing to do a bit of extra work to configure things my way.
Speaking of tight integration, what happens if Redhat's employees make
udev depend on systemd?

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Suggestion for getting rid of udev

[Michał Górny]

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

On Sat, 15 Oct 2011 00:06:03 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote
> 
> > We're imposing our deep integration because it's the only way to
> > make a compelling platform that "just works", forcing users to tell
> > the computer something the computer already knows is just plain
> > lazy and stupid.
> 
>   Eventually, that hits Mac or Windows-like levels of dictating 1 or 2
> sets of choices and nothing else.  If I wanted Mac or Windows, I'd be
> running Mac or Windows.  If the developers don't deliberately make my
> system break if /usr and /var aren't physically on / (and no
> initramfs), I'm willing to do a bit of extra work to configure things
> my way. Speaking of tight integration, what happens if Redhat's
> employees make udev depend on systemd?

And what happens, if GNU folks make GNU userland depend on Hurd?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Suggestion for getting rid of udev

[Mike Frysinger]

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

On Saturday 15 October 2011 03:29:54 Michał Górny wrote:
> On Sat, 15 Oct 2011 00:06:03 -0400 "Walter Dnes" wrote:
> > On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote
> > > We're imposing our deep integration because it's the only way to
> > > make a compelling platform that "just works", forcing users to tell
> > > the computer something the computer already knows is just plain
> > > lazy and stupid.
> > > 
> >   Eventually, that hits Mac or Windows-like levels of dictating 1 or 2
> > 
> > sets of choices and nothing else.  If I wanted Mac or Windows, I'd be
> > running Mac or Windows.  If the developers don't deliberately make my
> > system break if /usr and /var aren't physically on / (and no
> > initramfs), I'm willing to do a bit of extra work to configure things
> > my way. Speaking of tight integration, what happens if Redhat's
> > employees make udev depend on systemd?
> 
> And what happens, if GNU folks make GNU userland depend on Hurd?

with gnulib in place, they (directly) won't
-mike

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

Re: [gentoo-dev] Suggestion for getting rid of udev

[Joost Roeleveld]

On Saturday, October 15, 2011 09:29:54 AM Michał Górny wrote:
> On Sat, 15 Oct 2011 00:06:03 -0400
> 
> "Walter Dnes" <waltdnes@waltdnes.org> wrote:
> > On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote
> > 
> > > We're imposing our deep integration because it's the only way to
> > > make a compelling platform that "just works", forcing users to tell
> > > the computer something the computer already knows is just plain
> > > lazy and stupid.
> > > 
> >   Eventually, that hits Mac or Windows-like levels of dictating 1 or 2
> > 
> > sets of choices and nothing else.  If I wanted Mac or Windows, I'd be
> > running Mac or Windows.  If the developers don't deliberately make my
> > system break if /usr and /var aren't physically on / (and no
> > initramfs), I'm willing to do a bit of extra work to configure things
> > my way. Speaking of tight integration, what happens if Redhat's
> > employees make udev depend on systemd?
> 
> And what happens, if GNU folks make GNU userland depend on Hurd?

They'll finally get to version 1.x and Hurd can be used instead of the Linux 
kernel if someone wants to? :)

--
Joost

Re: [gentoo-dev] Suggestion for getting rid of udev

[Michał Górny]

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

On Wed, 12 Oct 2011 18:49:19 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 12 Oct 2011 23:00:23 +0530
> Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> > Then please continue with udev in package.mask and kindly stop
> > trying to impose your workflow on the rest of the world.
> 
> Isn't the point here that the desktop / GNOME OS guys are trying to
> impose their deep integration, tight coupling workflow upon the rest
> of the world?

What's the 'deep integration' here?

AFAICS the main point here is that you want to make udev capable of
guessing all your filesystem structure, and maybe even mounting it.
Yeah, sounds really KISS.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Suggestion for getting rid of udev

[Thomas Kahle]

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

On 09:09 Wed 12 Oct 2011, Walter Dnes wrote:
> > Goodbye desktop users then.
> > 
> > We recently dropped HAL. Now all the magic that was done by HAL (and
> > required udev anyway) is done through udev directly.
> 
>   My system worked just fine before HAL was introduced, thank you.  I
> always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask
> and my system continued to work just fine, thank you.  Given the great
> HAL fiasco, the fact that HAL has been incorporated into udev is yet one
> more reason for dropping udev <G>.

https://www.xkcd.com/963/



-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/

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

Re: [gentoo-dev] Suggestion for getting rid of udev

[Walter Dnes]

On Thu, Oct 13, 2011 at 10:12:52AM -0400, Thomas Kahle wrote

> https://www.xkcd.com/963/

  Xorg --configure

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Suggestion for getting rid of udev

[Canek Peláez Valdés]

On Fri, Oct 14, 2011 at 8:37 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Thu, Oct 13, 2011 at 10:12:52AM -0400, Thomas Kahle wrote
>
>> https://www.xkcd.com/963/
>
>  Xorg --configure

Funny, I haven't used a /etc/X11/Xorg.conf in years:

negra ~ # ll /etc/X11/
total 20
drwxr-xr-x 2 root root 4096 Sep 12 17:49 app-defaults
-rwxr-xr-x 1 root root 1301 Aug 31 15:54 chooser.sh
drwxr-xr-x 2 root root 4096 Sep 30 09:36 Sessions
-rwxr-xr-x 1 root root  923 Aug 31 15:54 startDM.sh
drwxr-xr-x 3 root root 4096 Aug 31 15:54 xinit
negra ~ #

It's great; it "just works". And it is thanks (in great part) to udev.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Suggestion for getting rid of udev

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/12/11 05:40, Walter Dnes wrote:
> Hi all
> 
> The other option is to drop udev entirely.  As an example, I
> suggest looking at Alpine Linux http://alpinelinux.org/  It's a
> lightweight server-oriented distro.  It uses busybox's mdev instead
> of udev, and some other mdev substitutes in place of standard
> packages.  It uses openrc.  Furthermore, "previous versions of
> Alpine were based on Gentoo" as per
> http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package so 
> there should be no problem with us borrowing back from Alpine.
> 
This is a joke right? All the desktop "infrastructure" depends on
that. Are you suggesting to make Gentoo an embedded/server only distro?

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOlTzUAAoJEPqDWhW0r/LC2rAQAI9+GgYyUZqOPcL8dXa/oDJP
8zAn1w6aJfYW1MJOLlFxx48pYC4G64xencGKUGMyCKdwNGHxEYIAnLIB1fjEIwKz
c5gFWjgZyOG1etDJblYtHUEdUDzqVz1EpFmyt/ASxJRsaCOTFv0NyG26tw4cumBT
Gpkf/qSwENnSNo+HlMdjlqUzioiSa9afZe/4IkZRKH8NL3UOXEd8Ud605L5YDJoC
uErGRamsdRP4XuNU9oB230QVHy2/7vsxZhtDJ3d22MHECF9rpdPfgmZ2zAmUe3ut
/NPau8xZG/1udf6REcIZHcg8ERXMl5hO38GuYoyO8/gtxcLLcFaDVMzTzLdaoWg/
H6rB9HhbhZYy9049sPtA2VP+jfCCdriLWpi6G1/XyotgK2e0zgGUIATPskf+Ge5N
Nb20Mr2fEbqTgd5SdcPDM4dq0y8at1u8WaAJDfvvy8mvEwwX42GZJK2wsMdY0x/k
G85zKQm7pZNnk0V17czUcnkbO+D8Ormw/wImMLrA9KidmC2FbHgPj4qOYAR6Dsso
0i6gvgCai+y0cymTnSYM99xo4KAU/ZKcqGsNtbUKaJ1IwR3tPgGLwHb70NPZF3e5
ssxtG4Su4wo2WGfMfNcPgjTA9hbYW2JGM2s4TH9+V7BVv+wW9b7osyiplJ3f0X7l
Kq7yoCCF499m/BMoTgot
=cicu
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Suggestion for getting rid of udev

[Rich Freeman]

On Wed, Oct 12, 2011 at 12:40 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>  Forking udev is probably not an option.  The udev lead developer is a
> Redhat employee, and his direction seems to be to drag everybody in
> Redhat's direction.  Our community doesn't have Redhat's billions.

We should note that RedHat is already spending their billions to make
dracut smarter, and if initramfs is good enough for RHEL then it
should be good enough for us if somebody just has to have /usr on a
separate device and needs some of the fancier udev rules to work on
boot.  For those who don't need dracut there was already a stated
desire to provide a simplified initramfs.  And, for less complex
setups, you don't need it at all.

My concern with something like dropping udev is that it would make us
different from every other desktop distro out there.  I'm not aware of
any distro packaging Gnome/KDE without udev.  Not having Redhat's
billions to me is a good reason to try to do things the same way that
Redhat does them - so that we're not re-inventing the wheel.

Gentoo is still a fairly meta distro and if users want to remove udev
they probably can do it without a great deal of hassle if they don't
want hot more hotplugish experience and don't use the big desktop
environments.  It just doesn't make sense to make that a default.  In
the same way I don't mind a list of CFLAGS that spans 3 lines but I'd
never advocate putting that into the default make.conf.

Rich

Re: [gentoo-dev] Suggestion for getting rid of udev

[Mike Frysinger]

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

On Wednesday 12 October 2011 09:26:12 Rich Freeman wrote:
> On Wed, Oct 12, 2011 at 12:40 AM, Walter Dnes wrote:
> >  Forking udev is probably not an option.  The udev lead developer is a
> > Redhat employee, and his direction seems to be to drag everybody in
> > Redhat's direction.  Our community doesn't have Redhat's billions.
> 
> We should note that RedHat is already spending their billions to make
> dracut smarter, and if initramfs is good enough for RHEL then it
> should be good enough for us if somebody just has to have /usr on a
> separate device and needs some of the fancier udev rules to work on
> boot.  For those who don't need dracut there was already a stated
> desire to provide a simplified initramfs.  And, for less complex
> setups, you don't need it at all.

i don't think this logic is that great.  RHEL/Fedora do a lot of things that 
they consider desirable but which are simply their opinion on the topic.

for a while there, they pretty much forced LVM down everyone's throat during 
the install.  it's been a while since i last installed/maintained those 
distros (thankfully), but their initramfs setups were always way more flaky 
than they should have been and fairly difficult to recover from.

the "firstboot" idea is another great example of "things not fully thought 
through ahead of time".  systemd is a good choice for some, but its desire to 
be Linux-specific and require recent kernels is a limitation.

if you want to use initramfs on your system, you certainly can.  if you want 
to do lvm/whatever rootfs, then feel free.  if you want to run systemd, np.  
you want to add bloat with firstboot, by all means.  but a Gentoo system will 
not require any of these things (unless you choose to customize your own 
system in such a way) regardless of how much money other distros throw at 
their own ideas.

note: i'm not advocating dropping udev by default as i think it's completely 
unrealistic, and unlike the other projects mentioned, has been widely adopted 
across pretty much all distros.  it also doesn't really address the 
*underlying* problem: package rules that require /usr to be mounted.
-mike

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

[gentoo-dev] Re: Suggestion for getting rid of udev

[Duncan]

Rich Freeman posted on Wed, 12 Oct 2011 09:26:12 -0400 as excerpted:

> My concern with something like dropping udev is that it would make us
> different from every other desktop distro out there.  I'm not aware of
> any distro packaging Gnome/KDE without udev.  Not having Redhat's
> billions to me is a good reason to try to do things the same way that
> Redhat does them - so that we're not re-inventing the wheel.

I'm sure you didn't mean that the way it looks, or next, we'd certainly 
be switching to binary-by-default.

However, you bring up a good point that I've seen repeated in one way or 
another in many discussions about Linux distros and how the compare and 
differ, and in particular, what makes the Linux ecosystem different from 
the Unix ecosystem before it, which ultimately so differentiated that 
each brand was effectively its own OS (as can still be seen in the 
various BSDs today, to some degree, as well as in the surviving 
commercial Unixen, despite POSIX and etc.).

The point as I've seen it repeatedly made, is that what tends to keep the 
various Linuxen compatible is that while each distro does choose its own 
points of differentiation and does indeed differ in those points from 
most others, due to the forces of free/libre and open source, if one ends 
up really better, the others all adapt pretty much the same thing, *AND* 
perhaps more importantly, with f/l/os...

--> Each point of difference requires a significant
--> investment of time and energy from a distro's devs
--> that they could otherwise avoid.

That economy of efficiency forces distros to choose the points of 
distinction they REALLY value, and work on them, while in other areas, 
it's much more efficient to just go with the mainline flow, because being 
different requires WORK, both to achieve, and to maintain, especially at 
FLOSS development speed.

(Of course, a subpoint can be mentioned as well, that in an all-volunteer 
community distro such as gentoo, to a rather large degree, the amount of 
resources the distro chooses to devote to any potential point of 
differentiation, depends on what individual developers choose to push as 
their own personal projects, and the degree to which they can motivate 
other devs and non-dev community volunteers to work with them toward that 
goal.)

Thus, the point I'd make and that I believe you were making is not that 
Gentoo can't be different, or we'd obviously be doing a binary distro 
like everyone else, but that we pick the differences which we value 
enough to develop and maintain, and while the customization that building 
from source allows is one of them, gentoo's not known as a "no-udev" 
distro now, and making it so by default is in practice going to cost 
resources that we simply don't have, so it's extremely unlikely to happen.

But gentoo /does/ value the ability of the administrator to make that 
sort of choice for themselves, and gentoo would not be gentoo, if it 
didn't try to preserve that choice where possible given development 
resource constraints, because that is one of the points of 
differentiation that gentoo has always focused on.  Individual apps and 
indeed, whole desktop environments, may require udev, but that doesn't 
mean the gentoo machine admin isn't free to choose alternatives that 
don't require it.

-- 
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: Suggestion for getting rid of udev

[Rich Freeman]

On Wed, Oct 12, 2011 at 10:16 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Thus, the point I'd make and that I believe you were making is not that
> Gentoo can't be different, or we'd obviously be doing a binary distro
> like everyone else, but that we pick the differences which we value
> enough to develop and maintain, and while the customization that building
> from source allows is one of them, gentoo's not known as a "no-udev"
> distro now, and making it so by default is in practice going to cost
> resources that we simply don't have, so it's extremely unlikely to happen.

Yup, that was basically what I was getting at.  We need to pick our
battles.  Being so different that we have to patch half of our
upstream packages to work with our userspace is just creating a mess.

It is bad enough that we have to patch half of our upstream packages
because they don't know how to make decent build systems.  :)

>
> But gentoo /does/ value the ability of the administrator to make that
> sort of choice for themselves, and gentoo would not be gentoo, if it
> didn't try to preserve that choice where possible given development
> resource constraints, because that is one of the points of
> differentiation that gentoo has always focused on.  Individual apps and
> indeed, whole desktop environments, may require udev, but that doesn't
> mean the gentoo machine admin isn't free to choose alternatives that
> don't require it.

I couldn't agree more.  Certainly if anybody running an mdev system
finds that some tweak to another package makes their life a lot easier
and it doesn't otherwise increase the distro's maintenance burden a
great deal, then they should submit a patch.  Much of the power of
Gentoo is that it gets out of the user's way when you want to do
things differently.

I think it will be a while before we see an mdev profile, however.

Rich

Re: [gentoo-dev] Suggestion for getting rid of udev

[Olivier Crête]

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

On Wed, 2011-10-12 at 00:40 -0400, Walter Dnes wrote:
> Hi all
> 
>   Recently, there was a firestorm on the gentoo-user list over the idea
> that udev would eventually require /usr to be on the same physical
> parition as /, or else use initramfs, which is its own can of worms. I'm
> not a programmer, let alone a developer.  Rather than merely ranting, I
> went and searched for an alternative.

You completely misunderstand what Kay wants, what we are saying that is
that you need to mount /usr at the same time as you mount /, which you
can still do in your initramfs, etc.

That said, we, the GNOME upstream, think that having a separate /usr is
a completely stupid idea.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

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

Re: [gentoo-dev] Suggestion for getting rid of udev

[Mike Frysinger]

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

On Thursday 13 October 2011 11:17:07 Olivier Crête wrote:
> That said, we, the GNOME upstream, think that having a separate /usr is
> a completely stupid idea.

considering GNOME's track record wrt what they think is a "good idea" in the 
UI land, i'm not sure this statement is terribly compelling
-mike

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

Re: [gentoo-dev] Suggestion for getting rid of udev

[Greg KH]

On Wed, Oct 12, 2011 at 12:40:23AM -0400, Walter Dnes wrote:
> Hi all
> 
>   Recently, there was a firestorm on the gentoo-user list over the idea
> that udev would eventually require /usr to be on the same physical
> parition as /, or else use initramfs, which is its own can of worms. I'm
> not a programmer, let alone a developer.  Rather than merely ranting, I
> went and searched for an alternative.

udev is not the problem here, please do not shoot the messenger.  And
read the documentation for what is going on before making statements
like "we have to replace udev", otherwise it comes across very foolish.

>   Forking udev is probably not an option.  The udev lead developer is a
> Redhat employee, and his direction seems to be to drag everybody in
> Redhat's direction.  Our community doesn't have Redhat's billions.

Since when was udev written by RedHat's billions?  You do know the
history of it, right?

>   The other option is to drop udev entirely.  As an example, I suggest
> looking at Alpine Linux http://alpinelinux.org/  It's a lightweight
> server-oriented distro.  It uses busybox's mdev instead of udev, and
> some other mdev substitutes in place of standard packages.

Haha, mdev, yeah right.

Have fun with that...

greg k-h