[gentoo-dev] RFC: virtual/libudev

[gentoo-dev] RFC: virtual/libudev

[Michał Górny]

[-- Attachment #1.1: Type: text/plain, Size: 938 bytes --]

Hello, all.

Since nowadays udev is bundled within systemd, we start having two
libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
the long story short, I would like to introduce a virtual for libudev
which would pull in either of those two.

There are three USE flags used in conditionals when depending on udev:
- gudev - for glib wrapper on udev,
- hwdb - to pull in hwids,
- static-libs.

The former two were previously provided by 'extras' USE flag,
and the third was unconditional.

I'm attaching an example virtual/libudev which does the job. Sadly,
because of the 'extras' compatibility it's a big ugly conditional.

An alternative would be to provide separate virtual/libudev
and virtual/libgudev; and maybe changing ebuilds not to depend on
[hwids] but rather pull in sys-apps/hwids directly (since that's what
the flag does).

What are you thoughts?

-- 
Best regards,
Michał Górny

[-- Attachment #1.2: libudev-0.ebuild --]
[-- Type: text/plain, Size: 943 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI=4

DESCRIPTION="Virtual for libudev providers"
HOMEPAGE=""
SRC_URI=""

LICENSE=""
SLOT="0"
KEYWORDS="alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64
	s390 sh sparc x86 ~x86-linux"
IUSE="gudev hwdb static-libs"

RDEPEND="
	gudev? (
		hwdb? (
			|| ( >=sys-fs/udev-171[gudev,hwdb,static-libs(+)?]
				<sys-fs/udev-171[extras]
				>=sys-apps/systemd-185[gudev,static-libs(+)?] )
		)
		!hwdb? (
			|| ( >=sys-fs/udev-171[gudev,static-libs(+)?]
				<sys-fs/udev-171[extras]
				>=sys-apps/systemd-185[gudev,static-libs(+)?] )
		)
	)
	!gudev? (
		hwdb? (
			|| ( >=sys-fs/udev-171[hwdb,static-libs(+)?]
				<sys-fs/udev-171[extras]
				>=sys-apps/systemd-185[static-libs(+)?] )
		)
		!hwdb? (
			|| ( sys-fs/udev[static-libs(+)?]
				>=sys-apps/systemd-185[static-libs(+)?] )
		)
	)"

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

Re: [gentoo-dev] RFC: virtual/libudev

[Alexis Ballier]

On Tue, 10 Jul 2012 17:18:00 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> The former two were previously provided by 'extras' USE flag,
> and the third was unconditional.

since udev-171 seems to be going stable, why not simply drop the
'extras' compatibility ?
then you could just use 'gudev?' usedeps it seems

A.

Re: [gentoo-dev] RFC: virtual/libudev

[Michał Górny]

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

On Tue, 10 Jul 2012 12:54:31 -0400
Alexis Ballier <aballier@gentoo.org> wrote:

> On Tue, 10 Jul 2012 17:18:00 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > The former two were previously provided by 'extras' USE flag,
> > and the third was unconditional.
> 
> since udev-171 seems to be going stable, why not simply drop the
> 'extras' compatibility ?
> then you could just use 'gudev?' usedeps it seems

I heard that people are still bound to old udev versions because of
kernel requirements introduced by newer ones.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: virtual/libudev

[William Hubbs]

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

On Tue, Jul 10, 2012 at 07:57:50PM +0200, Michał Górny wrote:
> On Tue, 10 Jul 2012 12:54:31 -0400
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Tue, 10 Jul 2012 17:18:00 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > The former two were previously provided by 'extras' USE flag,
> > > and the third was unconditional.
> > 
> > since udev-171 seems to be going stable, why not simply drop the
> > 'extras' compatibility ?
> > then you could just use 'gudev?' usedeps it seems
> 
> I heard that people are still bound to old udev versions because of
> kernel requirements introduced by newer ones.

The eventual plan is to kill off the extras use flag in favor of the
others. It is only there to allow packages that depended on udev[extras]
to be moved to depend on the correct use flag, so I think we should be
able to kill it at some point. I just haven't looked into doing that.

William


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

Re: [gentoo-dev] RFC: virtual/libudev

[Thomas Sachau]

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

Michał Górny schrieb:
> Hello, all.
> 
> Since nowadays udev is bundled within systemd, we start having two
> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
> the long story short, I would like to introduce a virtual for libudev
> which would pull in either of those two.
> 
> There are three USE flags used in conditionals when depending on udev:
> - gudev - for glib wrapper on udev,
> - hwdb - to pull in hwids,
> - static-libs.
> 
> The former two were previously provided by 'extras' USE flag,
> and the third was unconditional.
> 
> I'm attaching an example virtual/libudev which does the job. Sadly,
> because of the 'extras' compatibility it's a big ugly conditional.
> 
> An alternative would be to provide separate virtual/libudev
> and virtual/libgudev; and maybe changing ebuilds not to depend on
> [hwids] but rather pull in sys-apps/hwids directly (since that's what
> the flag does).
> 
> What are you thoughts?
> 

As discussed on IRC, there is still no consensus for installing the udev
files with systemd, which is the beginning for the block and the
virtual. So we should first sort that point out, before we even start to
think about an ebuild for an udev virtual.

So for now: A clear no, i am against adding a virtual/libudev ebuild.

-- 

Thomas Sachau
Gentoo Linux Developer




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

Re: [gentoo-dev] RFC: virtual/libudev

[Ben de Groot]

On 11 July 2012 03:23, Thomas Sachau <tommy@gentoo.org> wrote:
> Michał Górny schrieb:
>> Hello, all.
>>
>> Since nowadays udev is bundled within systemd, we start having two
>> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
>> the long story short, I would like to introduce a virtual for libudev
>> which would pull in either of those two.
>> [...]
>> What are you thoughts?
>
> As discussed on IRC, there is still no consensus for installing the udev
> files with systemd, which is the beginning for the block and the
> virtual. So we should first sort that point out, before we even start to
> think about an ebuild for an udev virtual.
>
> So for now: A clear no, i am against adding a virtual/libudev ebuild.

Me too.

When upstream moved the udev sources to the systemd repo, they
promised that udev would continue to be able to be used separately
from systemd. We should hold them to that promise.

If they break their promise (as it seems they are bent on doing),
then we should go ahead with the fork as discussed earlier. I'm sure
other distros such as Debian and Slackware would be happy to
join us in that effort.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[gentoo-dev] Re: RFC: virtual/libudev

[Duncan]

Ben de Groot posted on Wed, 11 Jul 2012 12:51:50 +0800 as excerpted:

> When upstream moved the udev sources to the systemd repo, they promised
> that udev would continue to be able to be used separately from systemd.
> We should hold them to that promise.
> 
> If they break their promise (as it seems they are bent on doing), then
> we should go ahead with the fork as discussed earlier. I'm sure other
> distros such as Debian and Slackware would be happy to join us in that
> effort.

Given the size of debian, I'd guess we'd likely be joining them, rather 
than the other way around, tho slack would I'd guess be joining us...

Regardless, I agree with the point, and yes, debian at least will 
certainly be doing something as they have non-linux to worry about too, 
tho OTOH they move slow enough they might indeed be joining us, size or 
no size.

-- 
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] RFC: virtual/libudev

[Michał Górny]

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

On Wed, 11 Jul 2012 12:51:50 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> On 11 July 2012 03:23, Thomas Sachau <tommy@gentoo.org> wrote:
> > Michał Górny schrieb:
> >> Hello, all.
> >>
> >> Since nowadays udev is bundled within systemd, we start having two
> >> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
> >> the long story short, I would like to introduce a virtual for
> >> libudev which would pull in either of those two.
> >> [...]
> >> What are you thoughts?
> >
> > As discussed on IRC, there is still no consensus for installing the
> > udev files with systemd, which is the beginning for the block and
> > the virtual. So we should first sort that point out, before we even
> > start to think about an ebuild for an udev virtual.
> >
> > So for now: A clear no, i am against adding a virtual/libudev
> > ebuild.
> 
> Me too.
> 
> When upstream moved the udev sources to the systemd repo, they
> promised that udev would continue to be able to be used separately
> from systemd. We should hold them to that promise.
> 
> If they break their promise (as it seems they are bent on doing),
> then we should go ahead with the fork as discussed earlier. I'm sure
> other distros such as Debian and Slackware would be happy to
> join us in that effort.

If we fork, then I would expect systemd to actually require its own
udev which means that systemd would need to build it anyway. What's
the point?

-- 
Best regards,
Michał Górny

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

[gentoo-dev] Re: RFC: virtual/libudev

[Duncan]

Michał Górny posted on Wed, 11 Jul 2012 09:15:10 +0200 as excerpted:

> On Wed, 11 Jul 2012 12:51:50 +0800 Ben de Groot <yngwin@gentoo.org>
> wrote:

>> When upstream moved the udev sources to the systemd repo, they promised
>> that udev would continue to be able to be used separately from systemd.
>> We should hold them to that promise.
>> 
>> If they break their promise (as it seems they are bent on doing), then
>> we should go ahead with the fork as discussed earlier. I'm sure other
>> distros such as Debian and Slackware would be happy to join us in that
>> effort.
> 
> If we fork, then I would expect systemd to actually require its own udev
> which means that systemd would need to build it anyway. What's the
> point?


Being able to choose not to run systemd at all?  If there's no need to 
build systemd, than what it requires is irrelevant.

-- 
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: RFC: virtual/libudev

[Michał Górny]

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

On Wed, 11 Jul 2012 08:27:48 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Michał Górny posted on Wed, 11 Jul 2012 09:15:10 +0200 as excerpted:
> 
> > On Wed, 11 Jul 2012 12:51:50 +0800 Ben de Groot <yngwin@gentoo.org>
> > wrote:
> 
> >> When upstream moved the udev sources to the systemd repo, they
> >> promised that udev would continue to be able to be used separately
> >> from systemd. We should hold them to that promise.
> >> 
> >> If they break their promise (as it seems they are bent on doing),
> >> then we should go ahead with the fork as discussed earlier. I'm
> >> sure other distros such as Debian and Slackware would be happy to
> >> join us in that effort.
> > 
> > If we fork, then I would expect systemd to actually require its own
> > udev which means that systemd would need to build it anyway. What's
> > the point?
> 
> 
> Being able to choose not to run systemd at all?  If there's no need
> to build systemd, than what it requires is irrelevant.

Who forces you to do otherwise? I really don't see what this thread is
all about.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: RFC: virtual/libudev

[Rich Freeman]

On Wed, Jul 11, 2012 at 4:27 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Being able to choose not to run systemd at all?  If there's no need to
> build systemd, than what it requires is irrelevant.

I think this discussion is getting sidetracked.

This didn't start out as a discussion about whether everybody should
have to have systemd on their systems - the answer to that is no.

The question is whether we should have a virtual for udev.  Right now
we're not sure how that is going to be packaged as far as systemd is
concerned, so it is premature to make that decision.  However, if we
do decide to fork udev then that means we'd almost certainly need to
have a virtual.  At that point we'd have two different udev
implementations in the tree - the fork and the one that comes bundled
with systemd.

Where things get dicey is if the two udev implementations start to
diverge and packages need to behave differently depending on which one
is installed - that would become a bit of a mess.  Hopefully it won't
come to that.

Rich

Re: [gentoo-dev] Re: RFC: virtual/libudev

[Ian Stakenvicius]

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

On 11/07/12 06:40 AM, Rich Freeman wrote:
> On Wed, Jul 11, 2012 at 4:27 AM, Duncan <1i5t5.duncan@cox.net>
> wrote:
>> Being able to choose not to run systemd at all?  If there's no
>> need to build systemd, than what it requires is irrelevant.
> 
> I think this discussion is getting sidetracked.
> 
> This didn't start out as a discussion about whether everybody
> should have to have systemd on their systems - the answer to that
> is no.
> 
> The question is whether we should have a virtual for udev.  Right
> now we're not sure how that is going to be packaged as far as
> systemd is concerned, so it is premature to make that decision.
> However, if we do decide to fork udev then that means we'd almost
> certainly need to have a virtual.  At that point we'd have two
> different udev implementations in the tree - the fork and the one
> that comes bundled with systemd.
> 
> Where things get dicey is if the two udev implementations start to 
> diverge and packages need to behave differently depending on which
> one is installed - that would become a bit of a mess.  Hopefully it
> won't come to that.
> 


..although it possibly could come to that, if the fork maintains
installation in /{bin,sbin,lib} while systemd-udev follows the
upstream move to /usr/{bin,sbin,lib}


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

iF4EAREIAAYFAk/9eUkACgkQ2ugaI38ACPAFiwD/fAERfjHE0kHItPuBnCqH+669
flblkcc4/rMkAOQk8GUA/3MKU1j374JmcF9omXDFDJcq4SEJszKNL3tJGjgs0i0v
=dahJ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: RFC: virtual/libudev

[Michael Mol]

On Wed, Jul 11, 2012 at 9:02 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 11/07/12 06:40 AM, Rich Freeman wrote:
>> On Wed, Jul 11, 2012 at 4:27 AM, Duncan <1i5t5.duncan@cox.net>
>> wrote:
>>> Being able to choose not to run systemd at all?  If there's no
>>> need to build systemd, than what it requires is irrelevant.
>>
>> I think this discussion is getting sidetracked.
>>
>> This didn't start out as a discussion about whether everybody
>> should have to have systemd on their systems - the answer to that
>> is no.
>>
>> The question is whether we should have a virtual for udev.  Right
>> now we're not sure how that is going to be packaged as far as
>> systemd is concerned, so it is premature to make that decision.
>> However, if we do decide to fork udev then that means we'd almost
>> certainly need to have a virtual.  At that point we'd have two
>> different udev implementations in the tree - the fork and the one
>> that comes bundled with systemd.
>>
>> Where things get dicey is if the two udev implementations start to
>> diverge and packages need to behave differently depending on which
>> one is installed - that would become a bit of a mess.  Hopefully it
>> won't come to that.
>>
>
>
> ..although it possibly could come to that, if the fork maintains
> installation in /{bin,sbin,lib} while systemd-udev follows the
> upstream move to /usr/{bin,sbin,lib}

I don't know the devs' familiarity or positions on it (or the history
of it here), but it's potentially relevant if you're looking at udev
and the /{bin,sbin,lib} vs /usr/{bin,sbin,lib} split.

Walter Dnes (very active over in gentoo-user) has put a lot of work
into testing and documenting mdev as an alternative for udev. There's
been a good deal of success there, up to and including it working with
GNOME 2. The work's been documented on the wiki:
https://wiki.gentoo.org/wiki/Mdev

-- 
:wq

Re: [gentoo-dev] Re: RFC: virtual/libudev

[Rich Freeman]

On Wed, Jul 11, 2012 at 9:49 AM, Michael Mol <mikemol@gmail.com> wrote:
> Walter Dnes (very active over in gentoo-user) has put a lot of work
> into testing and documenting mdev as an alternative for udev. There's
> been a good deal of success there, up to and including it working with
> GNOME 2. The work's been documented on the wiki:
> https://wiki.gentoo.org/wiki/Mdev

Unless you plan to stay on Gnome 2 forever or fork it you might want
to consider that Gnome at some point is going to require systemd, let
alone udev.  Whether that happens or not remains to be seen.

Not that mdev doesn't have its uses, but you're probably not going to
be running future releases of Gnome on it.

Rich

Re: [gentoo-dev] Re: RFC: virtual/libudev

[Michael Mol]

On Wed, Jul 11, 2012 at 10:06 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Jul 11, 2012 at 9:49 AM, Michael Mol <mikemol@gmail.com> wrote:
>> Walter Dnes (very active over in gentoo-user) has put a lot of work
>> into testing and documenting mdev as an alternative for udev. There's
>> been a good deal of success there, up to and including it working with
>> GNOME 2. The work's been documented on the wiki:
>> https://wiki.gentoo.org/wiki/Mdev
>
> Unless you plan to stay on Gnome 2 forever or fork it you might want
> to consider that Gnome at some point is going to require systemd, let
> alone udev.  Whether that happens or not remains to be seen.
>
> Not that mdev doesn't have its uses, but you're probably not going to
> be running future releases of Gnome on it.

I only mention Gnome 2 as an indicator of an example of system
complexity support achieved. I don't know what's going to happen with
future app interdependency with udev and systemd any more than anyone
else.

What's the generic laconic description of what udev and mdev do?
Hotplug event handler? Is there a significant reason Gentoo shouldn't
support selecting between such handlers? At the point where there's
discussion between using systemd's in-tree copy of udev and a fork of
udev, it seems appropriate to examine the possibility of a more
general selection mechanism.

Admittedly, with increased generality comes increased complexity. I
don't know exactly where increased long-term complexity would come
from, but my first guess would be redirecting where packages dependent
on hooking the hotplug handler place their scripts. Anything else I
can think of sounds more like an up-front effort cost, and not a
long-term one.

-- 
:wq

Re: [gentoo-dev] Re: RFC: virtual/libudev

[Walter Dnes]

On Wed, Jul 11, 2012 at 09:49:18AM -0400, Michael Mol wrote

> Walter Dnes (very active over in gentoo-user) has put a lot
> of work into testing and documenting mdev as an alternative for
> udev. There's been a good deal of success there, up to and including
> it working with GNOME 2. The work's been documented on the wiki:
> https://wiki.gentoo.org/wiki/Mdev

  I'm now testing automount under mdev.  No GUI required.  I hope to
have a wiki page up soon.

  As for GNOME and KDE, they're trying to become OS's in their own
right.  What can I say?  There are a lot of alternative desktop
environments and window managers.  That's my target.

-- 
Walter Dnes <waltdnes@waltdnes.org>

[gentoo-dev] udev <-> mdev

[Ian Stakenvicius]

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

On 11/07/12 11:40 PM, Walter Dnes wrote:
> On Wed, Jul 11, 2012 at 09:49:18AM -0400, Michael Mol wrote
>> Walter Dnes (very active over in gentoo-user) has put a lot of
>> work into testing and documenting mdev as an alternative for 
>> udev. There's been a good deal of success there, up to and
>> including it working with GNOME 2. The work's been documented on
>> the wiki: https://wiki.gentoo.org/wiki/Mdev
> 
> I'm now testing automount under mdev.  No GUI required.  I hope to 
> have a wiki page up soon.
> 
> As for GNOME and KDE, they're trying to become OS's in their own 
> right.  What can I say?  There are a lot of alternative desktop 
> environments and window managers.  That's my target.
> 

Out of curiosity, since mdev is (i assume) more than complete enough
to handle mounting, would it be possible to initially start with mdev
and then hand over control to udev (if there was a need for udev, that
is) , to avoid initramfs with separate /usr ?

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

iF4EAREIAAYFAk/+0x0ACgkQ2ugaI38ACPB1zwD/UTRcKHG91/q9RyovsvChaPWE
voF+oOAl5mE6A6hoN5UA/12KAC5XHModBZqNkWYuMqpB2q67t4fWHhp/w5lL7u7Z
=3uUp
-----END PGP SIGNATURE-----

Re: [gentoo-dev] udev <-> mdev

[Walter Dnes]

On Thu, Jul 12, 2012 at 09:37:33AM -0400, Ian Stakenvicius wrote

  First a disclaimer... I am not a C programmer, let alone a developer.
I feel like I've been dragged into this kicking and screaming in order
to save the Gentoo that I remember from a few years ago.

> Out of curiosity, since mdev is (i assume) more than complete enough
> to handle mounting, would it be possible to initially start with mdev
> and then hand over control to udev (if there was a need for udev, that
> is) , to avoid initramfs with separate /usr ?

  I think that's exactly how initramfs itself works.  You might be able
to use an initrd instead of initramfs.  See Zac Medico's posting at...
http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml
That was the clue that got me started on replacing udev with mdev.

  Once you have psuedo-filesystems and partitions mounted, you need to
shut down mdev and start up udev.  And make sure that
/proc/sys/kernel/hotplug points to udev.

  If you want to get fancy, you can boot from a separate small boot
partition, or for that matter a USB key.  Then either chroot or
pivot_root into the udev environment.  For pivot_root man pages see
http://linux.die.net/man/8/pivot_root and
http://linux.die.net/man/2/pivot_root

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] udev <-> mdev

[William Hubbs]

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

Hi all,

On Thu, Jul 12, 2012 at 04:07:41PM -0400, Walter Dnes wrote:
> On Thu, Jul 12, 2012 at 09:37:33AM -0400, Ian Stakenvicius wrote
> 
>   First a disclaimer... I am not a C programmer, let alone a developer.
> I feel like I've been dragged into this kicking and screaming in order
> to save the Gentoo that I remember from a few years ago.
> 
> > Out of curiosity, since mdev is (i assume) more than complete enough
> > to handle mounting, would it be possible to initially start with mdev
> > and then hand over control to udev (if there was a need for udev, that
> > is) , to avoid initramfs with separate /usr ?
> 
>   I think that's exactly how initramfs itself works.  You might be able
> to use an initrd instead of initramfs.  See Zac Medico's posting at...
> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml
> That was the clue that got me started on replacing udev with mdev.

initrd is deprecated and has been for a long time; you should use
initramfs.

>   Once you have psuedo-filesystems and partitions mounted, you need to
> shut down mdev and start up udev.  And make sure that
> /proc/sys/kernel/hotplug points to udev.

If you are using udev, /proc/sys/kernel/hotplug should be empty; do not
point this to udev.

Thanks,

William


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

[gentoo-dev] Re: udev <-> mdev

[Duncan]

William Hubbs posted on Thu, 12 Jul 2012 17:29:31 -0500 as excerpted:

>> And make sure that
>> /proc/sys/kernel/hotplug points to udev.
> 
> If you are using udev, /proc/sys/kernel/hotplug should be empty; do not
> point this to udev.

Yes.  I've not changed that setting from whatever the default is, and I 
guess udev moved its hook out from there quite some time ago so it's 
pointing at nothing, but having that actually point to something is known 
in kernel circles to lead to a lot of unnecessary grief.  They're 
seriously thinking about (and may be planning on) removing that option 
from the kernel entirely, to keep people configuring their first kernels 
from getting themselves in trouble, but of course that's now part of the 
kernel/userspace interface, so it isn't allowed to just disappear like 
kernel/kernel interfaces can.  At minimum they'd likely have to have it 
on the deprecation and removal schedule for awhile.  (I've not checked to 
see if it's there already.)

-- 
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: udev <-> mdev

[Walter Dnes]

On Fri, Jul 13, 2012 at 05:58:25AM +0000, Duncan wrote

> They're seriously thinking about (and may be planning on) removing
> that option from the kernel entirely, to keep people configuring
> their first kernels from getting themselves in trouble, but of course
> that's now part of the kernel/userspace interface, so it isn't allowed
> to just disappear like kernel/kernel interfaces can.  At minimum
> they'd likely have to have it on the deprecation and removal schedule
> for awhile.  (I've not checked to see if it's there already.)

  So what happens to people using mdev?  Do we have to switch from
Linu-x to Lenna-x?

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Re: udev <-> mdev

[Richard Yao]

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

On 07/13/2012 04:04 PM, Walter Dnes wrote:
> On Fri, Jul 13, 2012 at 05:58:25AM +0000, Duncan wrote
> 
>> They're seriously thinking about (and may be planning on) removing
>> that option from the kernel entirely, to keep people configuring
>> their first kernels from getting themselves in trouble, but of course
>> that's now part of the kernel/userspace interface, so it isn't allowed
>> to just disappear like kernel/kernel interfaces can.  At minimum
>> they'd likely have to have it on the deprecation and removal schedule
>> for awhile.  (I've not checked to see if it's there already.)
> 
>   So what happens to people using mdev?  Do we have to switch from
> Linu-x to Lenna-x?
> 

mdev would need to switch to the netlink hotplug interface.


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

Re: [gentoo-dev] Re: udev <-> mdev

[Maxim Kammerer]

On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao <ryao@gentoo.org> wrote:
> mdev would need to switch to the netlink hotplug interface.

I think that's quite unlikely, since mdev is not a daemon. Perhaps by
the time /proc/sys/kernel/hotplug is gone, mdev advocates will have
settled on some early udev fork. [1]

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

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] Re: udev <-> mdev

[Walter Dnes]

On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
> On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao <ryao@gentoo.org> wrote:
> > mdev would need to switch to the netlink hotplug interface.
> 
> I think that's quite unlikely, since mdev is not a daemon. Perhaps by
> the time /proc/sys/kernel/hotplug is gone, mdev advocates will have
> settled on some early udev fork. [1]

  Do you realize this would effectively kill linux in the embedded
device area?  Udev, even without the systemd code, is simply to large
for embedded devices.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Re: udev <-> mdev

[Canek Peláez Valdés]

On Fri, Jul 13, 2012 at 7:13 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
>> On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao <ryao@gentoo.org> wrote:
>> > mdev would need to switch to the netlink hotplug interface.
>>
>> I think that's quite unlikely, since mdev is not a daemon. Perhaps by
>> the time /proc/sys/kernel/hotplug is gone, mdev advocates will have
>> settled on some early udev fork. [1]
>
>   Do you realize this would effectively kill linux in the embedded
> device area?  Udev, even without the systemd code, is simply to large
> for embedded devices.

The guys from ProFUSION would disagree with you:

http://profusion.mobi/

It is a "a software development company focused on embedded systems",
and several of its employees contribute code and ideas for systemd, so
they also use udev. For embedded systems.

The idea that udev "is simply to large" is simply incorrect, I believe.

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] Re: udev <-> mdev

[Michael Mol]

On Fri, Jul 13, 2012 at 8:13 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
>> On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao <ryao@gentoo.org> wrote:
>> > mdev would need to switch to the netlink hotplug interface.
>>
>> I think that's quite unlikely, since mdev is not a daemon. Perhaps by
>> the time /proc/sys/kernel/hotplug is gone, mdev advocates will have
>> settled on some early udev fork. [1]
>
>   Do you realize this would effectively kill linux in the embedded
> device area?  Udev, even without the systemd code, is simply to large
> for embedded devices.

I'll venture a guess the solution will be to create a shim daemon
which turns around and launches udev.

-- 
:wq

Re: [gentoo-dev] Re: udev <-> mdev

[Walter Dnes]

On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote

> I'll venture a guess the solution will be to create a shim daemon
> which turns around and launches udev.

  A quicker-and-dirtier solution would be to create a shim daemon that
runs under the the name "udev", and passes all calls to /sbin/mdev.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Re: udev <-> mdev

[Michael Mol]

On Fri, Jul 13, 2012 at 9:10 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote
>
>> I'll venture a guess the solution will be to create a shim daemon
>> which turns around and launches udev.
>
>   A quicker-and-dirtier solution would be to create a shim daemon that
> runs under the the name "udev", and passes all calls to /sbin/mdev.

... and that's what I thought I'd typed. -.-


-- 
:wq

Re: [gentoo-dev] Re: udev <-> mdev

[Olivier Crête]

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

On Fri, 2012-07-13 at 21:10 -0400, Walter Dnes wrote:
> On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote
> 
> > I'll venture a guess the solution will be to create a shim daemon
> > which turns around and launches udev.
> 
>   A quicker-and-dirtier solution would be to create a shim daemon that
> runs under the the name "udev", and passes all calls to /sbin/mdev.

Seriously, mdev is a just a bad and now useless hack, it does nothing
more than using devtmpfs. You do not need udev for a very simple system.
If you system is a bit more complicated, than udev is what you want. It
works fine on millions of shipping devices.

And on any new embedded platform, one should seriously think about using
systemd too. It is very lean, replaces most of the giant, unmaintainable
shellscripts that you find in many devices with smaller compiled code,
and was designed to be a good fit for embedded devices.

-- 
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] Re: udev <-> mdev

[Rich Freeman]

On Fri, Jul 13, 2012 at 9:21 PM, Olivier Crête <tester@gentoo.org> wrote:
> And on any new embedded platform, one should seriously think about using
> systemd too. It is very lean, replaces most of the giant, unmaintainable
> shellscripts that you find in many devices with smaller compiled code,
> and was designed to be a good fit for embedded devices.

Fair point here - for an embedded device where memory is THAT tight
I'd wonder if ditching the shell might be an attainable goal.  C has
to be more memory-efficient.

Rich

Re: [gentoo-dev] Re: udev <-> mdev

[Luca Barbato]

On 07/14/2012 03:21 AM, Olivier Crête wrote:
> Seriously, mdev is a just a bad and now useless hack, it does nothing
> more than using devtmpfs. You do not need udev for a very simple system.
> If you system is a bit more complicated, than udev is what you want. It
> works fine on millions of shipping devices.
> 
> And on any new embedded platform, one should seriously think about using
> systemd too. It is very lean, replaces most of the giant, unmaintainable
> shellscripts that you find in many devices with smaller compiled code,
> and was designed to be a good fit for embedded devices.

Last time I looked at systemd it was anything that lean.

Obviously you can say that if you already need dbus and glib and ...
${systemd_deplist} it doesn't count.

Likewise if you are already using busybox it comes with a quite rich shell.

Most depends on what you consider embedded.

lu

-- 

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

Re: [gentoo-dev] Re: udev <-> mdev

[Maxim Kammerer]

On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> Do you realize this would effectively kill linux in the embedded
> device area?  Udev, even without the systemd code, is simply to large
> for embedded devices.

What's “too large”? Udev already looks pretty small to me (116k udevd,
50k libudev, 500k resident memory), and I didn't even try compiling it
with all extra features switched off. If that's too large for an
embedded device, does that device really need (or can handle) anything
more than devtmpfs?

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] Re: udev <-> mdev

[Walter Dnes]

On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote
> On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> > Do you realize this would effectively kill linux in the embedded
> > device area?  Udev, even without the systemd code, is simply to large
> > for embedded devices.
> 
> What's ?too large?? Udev already looks pretty small to me (116k udevd,
> 50k libudev, 500k resident memory), and I didn't even try compiling it
> with all extra features switched off. If that's too large for an
> embedded device, does that device really need (or can handle) anything
> more than devtmpfs?

  What does "equery depgraph" show for udev?  Since I don't have udev
installed, I can't check it here.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Re: udev <-> mdev

[Michael Mol]

On Fri, Jul 13, 2012 at 9:22 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote
>> On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>> > Do you realize this would effectively kill linux in the embedded
>> > device area?  Udev, even without the systemd code, is simply to large
>> > for embedded devices.
>>
>> What's ?too large?? Udev already looks pretty small to me (116k udevd,
>> 50k libudev, 500k resident memory), and I didn't even try compiling it
>> with all extra features switched off. If that's too large for an
>> embedded device, does that device really need (or can handle) anything
>> more than devtmpfs?
>
>   What does "equery depgraph" show for udev?  Since I don't have udev
> installed, I can't check it here.


sys-fs/udev-114:
 [  0]  sys-fs/udev-114
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  sys-apps/baselayout-2.1-r1

sys-fs/udev-115-r1:
 [  0]  sys-fs/udev-115-r1
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  sys-apps/baselayout-2.1-r1

sys-fs/udev-119:
 [  0]  sys-fs/udev-119
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  sys-apps/baselayout-2.1-r1

sys-fs/udev-124-r1:
 [  0]  sys-fs/udev-124-r1
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  sys-apps/baselayout-2.1-r1

sys-fs/udev-124-r2:
 [  0]  sys-fs/udev-124-r2
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  sys-apps/baselayout-2.1-r1

sys-fs/udev-141:
 [  0]  sys-fs/udev-141
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  sys-apps/baselayout-2.1-r1

sys-fs/udev-141-r1:
 [  0]  sys-fs/udev-141-r1
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  sys-apps/baselayout-2.1-r1

sys-fs/udev-146-r1:
 [  0]  sys-fs/udev-146-r1
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  sys-apps/acl-2.2.51
 [  1]  sys-apps/usbutils-004
 [  1]  virtual/libusb-0
 [  1]  sys-apps/pciutils-3.1.9-r1
 [  1]  dev-libs/glib-2.30.3
 [  1]  sys-apps/util-linux-2.20.1-r2
 [  1]  dev-util/gperf-3.0.4
 [  1]  sys-apps/baselayout-2.1-r1

sys-fs/udev-149:
 [  0]  sys-fs/udev-149
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  sys-apps/acl-2.2.51
 [  1]  sys-apps/usbutils-004
 [  1]  virtual/libusb-0
 [  1]  sys-apps/pciutils-3.1.9-r1
 [  1]  dev-libs/glib-2.30.3
 [  1]  sys-apps/util-linux-2.20.1-r2
 [  1]  dev-util/gperf-3.0.4
 [  1]  virtual/pkgconfig-0
 [  1]  virtual/os-headers-0
 [  1]  app-text/tree-1.6.0-r1
 [  1]  sys-apps/baselayout-2.1-r1

sys-fs/udev-151-r4:
 [  0]  sys-fs/udev-151-r4
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  sys-apps/acl-2.2.51
 [  1]  sys-apps/usbutils-004
 [  1]  virtual/libusb-0
 [  1]  sys-apps/pciutils-3.1.9-r1
 [  1]  dev-libs/glib-2.30.3
 [  1]  sys-apps/util-linux-2.20.1-r2
 [  1]  dev-util/gperf-3.0.4
 [  1]  virtual/pkgconfig-0
 [  1]  virtual/os-headers-0
 [  1]  app-text/tree-1.6.0-r1
 [  1]  sys-apps/baselayout-2.1-r1

sys-fs/udev-164-r2:
 [  0]  sys-fs/udev-164-r2
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  sys-apps/acl-2.2.51
 [  1]  sys-apps/usbutils-004
 [  1]  virtual/libusb-0
 [  1]  sys-apps/pciutils-3.1.9-r1
 [  1]  dev-libs/glib-2.30.3
 [  1]  sys-apps/util-linux-2.20.1-r2
 [  1]  dev-util/gperf-3.0.4
 [  1]  virtual/pkgconfig-0
 [  1]  virtual/os-headers-0
 [  1]  app-text/tree-1.6.0-r1
 [  1]  sys-apps/baselayout-2.1-r1

sys-fs/udev-171-r5:
 [  0]  sys-fs/udev-171-r5
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  sys-apps/acl-2.2.51
 [  1]  dev-libs/glib-2.30.3
 [  1]  dev-libs/gobject-introspection-1.30.0-r2
 [  1]  virtual/libusb-0
 [  1]  sys-apps/util-linux-2.20.1-r2
 [  1]  dev-util/gperf-3.0.4
 [  1]  virtual/pkgconfig-0
 [  1]  virtual/os-headers-0
 [  1]  app-text/tree-1.6.0-r1
 [  1]  sys-apps/usbutils-004
 [  1]  sys-apps/hwids-99999999
 [  1]  sys-apps/pciutils-3.1.9-r2
 [  1]  sys-apps/pciutils-3.1.9-r1
 [  1]  sys-apps/pciutils-3.1.7
 [  1]  sys-apps/baselayout-2.1-r1

sys-fs/udev-171-r6:
 [  0]  sys-fs/udev-171-r6
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  dev-libs/glib-2.30.3
 [  1]  dev-libs/gobject-introspection-1.30.0-r2
 [  1]  virtual/libusb-0
 [  1]  sys-apps/util-linux-2.20.1-r2
 [  1]  dev-util/gperf-3.0.4
 [  1]  virtual/pkgconfig-0
 [  1]  virtual/os-headers-0
 [  1]  app-text/tree-1.6.0-r1
 [  1]  sys-apps/usbutils-004
 [  1]  sys-apps/hwids-99999999
 [  1]  sys-apps/pciutils-3.1.9-r2
 [  1]  sys-apps/pciutils-3.1.9-r1
 [  1]  sys-apps/pciutils-3.1.7
 [  1]  sys-apps/baselayout-2.1-r1

sys-fs/udev-182-r2:
 [  0]  sys-fs/udev-182-r2
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  dev-libs/glib-2.30.3
 [  1]  dev-libs/gobject-introspection-1.30.0-r2
 [  1]  sys-apps/kmod-9999
 [  1]  sys-apps/util-linux-2.20.1-r2
 [  1]  dev-util/gperf-3.0.4
 [  1]  virtual/pkgconfig-0
 [  1]  virtual/os-headers-0
 [  1]  dev-util/gtk-doc-1.18-r1
 [  1]  sys-apps/usbutils-004
 [  1]  sys-apps/pciutils-3.1.9-r1
 [  1]  sys-apps/pciutils-3.1.7
 [  1]  sys-fs/udev-init-scripts-9999

sys-fs/udev-182-r3:
 [  0]  sys-fs/udev-182-r3
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  dev-libs/glib-2.30.3
 [  1]  dev-libs/gobject-introspection-1.30.0-r2
 [  1]  sys-apps/kmod-9999
 [  1]  sys-apps/util-linux-2.20.1-r2
 [  1]  dev-util/gperf-3.0.4
 [  1]  virtual/pkgconfig-0
 [  1]  virtual/os-headers-0
 [  1]  dev-util/gtk-doc-1.18-r1
 [  1]  sys-apps/hwids-99999999
 [  1]  sys-fs/udev-init-scripts-9999

sys-fs/udev-186:
 [  0]  sys-fs/udev-186
 [  1]  dev-libs/glib-2.30.3
 [  1]  dev-libs/gobject-introspection-1.30.0-r2
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  sys-apps/kmod-9999
 [  1]  sys-apps/util-linux-2.20.1-r2
 [  1]  dev-util/gperf-3.0.4
 [  1]  dev-util/intltool-0.50.2
 [  1]  virtual/pkgconfig-0
 [  1]  virtual/os-headers-0
 [  1]  dev-util/gtk-doc-1.18-r1
 [  1]  sys-devel/automake-1.11.1
 [  1]  sys-devel/automake-1.12.1
 [  1]  sys-devel/autoconf-2.68
 [  1]  sys-devel/libtool-2.4-r1
 [  1]  sys-apps/hwids-99999999
 [  1]  sys-fs/udev-init-scripts-9999

sys-fs/udev-9999:
 [  0]  sys-fs/udev-9999
 [  1]  sys-libs/libselinux-2.1.9-r1
 [  1]  dev-libs/glib-2.30.3
 [  1]  dev-libs/gobject-introspection-1.30.0-r2
 [  1]  sys-apps/kmod-9999
 [  1]  sys-apps/util-linux-2.20.1-r2
 [  1]  dev-util/gperf-3.0.4
 [  1]  virtual/pkgconfig-0
 [  1]  virtual/os-headers-0
 [  1]  dev-util/gtk-doc-1.18-r1
 [  1]  app-text/tree-1.6.0-r1
 [  1]  dev-vcs/git-1.7.8.6
 [  1]  sys-devel/automake-1.11.1
 [  1]  sys-devel/automake-1.12.1
 [  1]  sys-devel/autoconf-2.68
 [  1]  sys-devel/libtool-2.4-r1
 [  1]  sys-apps/hwids-99999999
 [  1]  sys-fs/udev-init-scripts-9999


-- 
:wq

Re: [gentoo-dev] Re: udev <-> mdev

[Canek Peláez Valdés]

On Fri, Jul 13, 2012 at 8:28 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Fri, Jul 13, 2012 at 9:22 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>> On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote
>>> On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>>> > Do you realize this would effectively kill linux in the embedded
>>> > device area?  Udev, even without the systemd code, is simply to large
>>> > for embedded devices.
>>>
>>> What's ?too large?? Udev already looks pretty small to me (116k udevd,
>>> 50k libudev, 500k resident memory), and I didn't even try compiling it
>>> with all extra features switched off. If that's too large for an
>>> embedded device, does that device really need (or can handle) anything
>>> more than devtmpfs?
>>
>>   What does "equery depgraph" show for udev?  Since I don't have udev
>> installed, I can't check it here.

[snip]

> sys-fs/udev-186:
>  [  0]  sys-fs/udev-186
>  [  1]  dev-libs/glib-2.30.3
>  [  1]  dev-libs/gobject-introspection-1.30.0-r2
>  [  1]  sys-libs/libselinux-2.1.9-r1
>  [  1]  sys-apps/kmod-9999
>  [  1]  sys-apps/util-linux-2.20.1-r2
>  [  1]  dev-util/gperf-3.0.4
>  [  1]  dev-util/intltool-0.50.2
>  [  1]  virtual/pkgconfig-0
>  [  1]  virtual/os-headers-0
>  [  1]  dev-util/gtk-doc-1.18-r1
>  [  1]  sys-devel/automake-1.11.1
>  [  1]  sys-devel/automake-1.12.1
>  [  1]  sys-devel/autoconf-2.68
>  [  1]  sys-devel/libtool-2.4-r1
>  [  1]  sys-apps/hwids-99999999
>  [  1]  sys-fs/udev-init-scripts-9999

A lot of that is optional. The only hard dependencies are:

>=sys-apps/kmod-5
>=sys-apps/util-linux-2.20
dev-util/gperf
>=dev-util/intltool-0.40.0
virtual/pkgconfig
virtual/os-headers

Everything else is optional. I repeat: the idea that udev is somewhat
"bloated" or "fat" is really incorrect.

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] Re: udev <-> mdev

[Canek Peláez Valdés]

On Fri, Jul 13, 2012 at 9:32 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
[snip]
> A lot of that is optional. The only hard dependencies are:
>
>>=sys-apps/kmod-5
>>=sys-apps/util-linux-2.20
> dev-util/gperf
>>=dev-util/intltool-0.40.0
> virtual/pkgconfig
> virtual/os-headers
>
> Everything else is optional. I repeat: the idea that udev is somewhat
> "bloated" or "fat" is really incorrect.

Little correction: inherit autotools brings things like automake and
libtool, but then again, almost *every* Gentoo installation has those.

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] Re: udev <-> mdev

[Luca Barbato]

On 07/14/2012 04:34 AM, Canek Peláez Valdés wrote:
> On Fri, Jul 13, 2012 at 9:32 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> [snip]
>> A lot of that is optional. The only hard dependencies are:
>>
>>> =sys-apps/kmod-5
>>> =sys-apps/util-linux-2.20
>> dev-util/gperf
>>> =dev-util/intltool-0.40.0
>> virtual/pkgconfig
>> virtual/os-headers
>>
>> Everything else is optional. I repeat: the idea that udev is somewhat
>> "bloated" or "fat" is really incorrect.

> Little correction: inherit autotools brings things like automake and
> libtool, but then again, almost *every* Gentoo installation has those.

build dependencies should not count. =)

The bare udev shouldn't be that huge, then you start look at the glib
integration and such and it might get a bit more than you'd like.

Forking udev and making sure it stays as lean as possible isn't that bad.

Making mdev a bit richer and enjoy the speed advantage of busybox over
stand alone shells could be another option.

Most of the perceived speed in non-shell init systems is due not having
to spawn as many processes. A full busybox wouldn't spawn many processes.

lu

-- 

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

Re: [gentoo-dev] Re: udev <-> mdev

[Walter Dnes]

On Sun, Jul 29, 2012 at 01:38:28PM +0200, Luca Barbato wrote

> Forking udev and making sure it stays as lean as possible isn't that bad.

  That describes mdev to a T.  No need to re-invent the wheel.

> Making mdev a bit richer and enjoy the speed advantage of busybox
> over stand alone shells could be another option.

  The busybox people would probably not want "additional functionality"
built-in.  A better route would be "mdev helper programs" or "shims"
that we can add to Gentoo as required.  Actually, shell scripts
launched by /etc/mdev.conf can be quite powerful.  E.g.  wiki page
https://wiki.gentoo.org/wiki/Mdev/Automount_USB has ash scripts to
implement auto(un)mounting of USB devices.  It works for me, but I'm
waiting for feedback from other users before moving it out of beta
("Work In Progress") status.  Once I'm confident in the scripts, I'll
link to them from the main mdev page at
https://wiki.gentoo.org/wiki/Mdev  In case you're wondering, I'm not a
C programmer, so scripting was the only available tool for me.

> Most of the perceived speed in non-shell init systems is due not
> having to spawn as many processes. A full busybox wouldn't spawn
> many processes.

  It would be an interesting project to make a busybox-based Gentoo
fork.  But there are differences between busybox utilities and
standalone gnu utilities.  This is especially important for a
source-based distro like Gentoo, where all sorts of gnu utilities
get excercised by build scripts each time you do an update.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Re: udev <-> mdev

[William Hubbs]

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

On Fri, Jul 13, 2012 at 08:13:43PM -0400, Walter Dnes wrote:
> On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
> > On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao <ryao@gentoo.org> wrote:
> > > mdev would need to switch to the netlink hotplug interface.
> > 
> > I think that's quite unlikely, since mdev is not a daemon. Perhaps by
> > the time /proc/sys/kernel/hotplug is gone, mdev advocates will have
> > settled on some early udev fork. [1]
> 
>   Do you realize this would effectively kill linux in the embedded
> device area?  Udev, even without the systemd code, is simply to large
> for embedded devices.

What about using devtmpfs alone?

William

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

Re: [gentoo-dev] Re: udev <-> mdev

[Sylvain Alain]

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

Hi all, about the Mdev stuff, Slashbeast from Funtoo.org started that
project a while ago.

https://github.com/slashbeast/mdev-like-a-boss

I think that it's actually working pretty good on his box.

Some Coredevs from Funtoo are actually running with that stuff.

Sylvain

2012/7/13 William Hubbs <williamh@gentoo.org>

> On Fri, Jul 13, 2012 at 08:13:43PM -0400, Walter Dnes wrote:
> > On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
> > > On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao <ryao@gentoo.org> wrote:
> > > > mdev would need to switch to the netlink hotplug interface.
> > >
> > > I think that's quite unlikely, since mdev is not a daemon. Perhaps by
> > > the time /proc/sys/kernel/hotplug is gone, mdev advocates will have
> > > settled on some early udev fork. [1]
> >
> >   Do you realize this would effectively kill linux in the embedded
> > device area?  Udev, even without the systemd code, is simply to large
> > for embedded devices.
>
> What about using devtmpfs alone?
>
> William
>



-- 
Salut
alp
Sylvain

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

Re: [gentoo-dev] Re: udev <-> mdev

[Canek Peláez Valdés]

On Sat, Jul 14, 2012 at 12:35 AM, Sylvain Alain <d2racing911@gmail.com> wrote:
> Hi all, about the Mdev stuff, Slashbeast from Funtoo.org started that
> project a while ago.
>
> https://github.com/slashbeast/mdev-like-a-boss
>
> I think that it's actually working pretty good on his box.
>
> Some Coredevs from Funtoo are actually running with that stuff.

I don't think anybody has ever suggested that it's not possible to run
mdev instead of udev: as Walter has proved, it is indeed possible.

The question Olivier and William are making is (if I understand
correctly) if you don't need the features of udev, then why not use
only devtmpfs. I think everyone agrees that mdev doesn't have (and
probably never will nor want) all the features that udev has.

Seeing all the trouble some people have taken to make their systems
work with mdev just to avoid having to use an initramfs, I really
wonder how much effort it would have taken the simple task of learning
one step more when updating kernels and switch to use an initramfs.

Then again, everyone is entitled to work in the features (or
anti-features) they want. It is FLOSS after all.

Just the 0.02 ${CURRENCY} of a happy udev/systemd user (I'm really
happy the merged the two project trees).

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] Re: udev <-> mdev

[Peter Stuge]

Canek Peláez Valdés wrote:
> Seeing all the trouble some people have taken to make their systems
> work with mdev just to avoid having to use an initramfs, I really
> wonder how much effort it would have taken the simple task of learning
> one step more when updating kernels and switch to use an initramfs.

I think udev, systemd, and initramfs are orthogonal concepts.

FWIW I've built more or less deeply embedded Linux systems with
Gentoo and without, for years.

I stopped using init scripts long before I started using Gentoo in 2004.

systemd is in most regards a significant improvement over everything
that was previously available.

The few regards where it isn't are outweighed fairly easily by the
value of same process management both on desktop Linux and embedded
Linux.

On deeply embedded systems with say 2 or 4 Mbyte flash I might choose
something other than systemd however. As was pointed out, such a
system may also not need to be very dynamic, so losing udev is not
neccessarily a problem. If they do need to be dynamic, then will have
to make some room for udev as well.

Anyone who tries to argue that initramfs would be good for me to
have on my systems should brace themselves for a mouthful of foul
swedish language coming their way! ;)


//Peter

Re: [gentoo-dev] Re: udev <-> mdev

[Canek Peláez Valdés]

On Sat, Jul 14, 2012 at 4:02 PM, Peter Stuge <peter@stuge.se> wrote:
[snip]
> Anyone who tries to argue that initramfs would be good for me to
> have on my systems should brace themselves for a mouthful of foul
> swedish language coming their way! ;)

I don't think anyone has argued it's "good" for anyone. An initramfs
it's just now the only supported way (by udev and systemd) to have a
separated /usr partition.

If your /usr is in the same partition as /, then udev and systemd
supports your configuration *without* an initramfs. I have it like
that in a couple of servers, and actually I only use an initramfs in
my laptop and desktop because I like plymouth.

If your /usr is in a separate partition as /, and you don't want to
use an initramfs, you're free to do so. Only then udev (and systemd,
if you use it) will not support your configuration, and any problem
you encounter will be ignored in their mailing lists/bugzillas.

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] Re: udev <-> mdev

[Peter Stuge]

Canek Peláez Valdés wrote:
> An initramfs it's just now the only supported way (by udev and
> systemd) to have a separated /usr partition.

Yes sure. I considered separate partitions in the 90s, let's just
say that I don't see the problem that many on the internet cry about.

Using multiple filesystems in a system allows doing very nice things,
but /usr /var /whatever is waay too clumsy, to do the nice things
there needs to be more cleverness, which we're not neccessarily ready
for just yet.


//Peter

[gentoo-dev] Re: udev <-> mdev

[Duncan]

Canek Peláez Valdés posted on Sat, 14 Jul 2012 16:29:19 -0500 as
excerpted:

> If your /usr is in the same partition as /, then udev and systemd
> supports your configuration *without* an initramfs. I have it like that
> in a couple of servers, and actually I only use an initramfs in my
> laptop and desktop because I like plymouth.
> 
> If your /usr is in a separate partition as /, and you don't want to use
> an initramfs, you're free to do so. Only then udev (and systemd,
> if you use it) will not support your configuration, and any problem you
> encounter will be ignored in their mailing lists/bugzillas.


BTW, any "gentooish" documentation out there on rootfs as tmpfs, with 
/etc and the like mounted on top of it, operationally ro, rw remounted 
for updates?

That's obviously going to take an initr*, which I've never really 
understood to the point I'm comfortable with my ability to recover from 
problems so I've not run one since my Mandrake era, but that's a status 
that can change, and what with the /usr move and some computer problems I 
just finished dealing with, I've been thinking about the possibility 
lately.  So if there's some good docs on the topic someone can point me 
at, I'd be grateful. =:^)

I'm aware of the issues with /etc/mtab and have googled a bit on the 
workarounds, but that looks like a decent amount of work, and if I'm 
going to do that, I might as well invest the time and do it right, initr*, 
full tmpfs rootfs with everything non-volatile mounted on top, the whole 
shebang!

-- 
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: udev <-> mdev

[Rich Freeman]

On Sat, Jul 14, 2012 at 7:38 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> BTW, any "gentooish" documentation out there on rootfs as tmpfs, with
> /etc and the like mounted on top of it, operationally ro, rw remounted
> for updates?
>
> That's obviously going to take an initr*, which I've never really
> understood to the point I'm comfortable with my ability to recover from
> problems so I've not run one since my Mandrake era, but that's a status
> that can change, and what with the /usr move and some computer problems I
> just finished dealing with, I've been thinking about the possibility
> lately.  So if there's some good docs on the topic someone can point me
> at, I'd be grateful. =:^)

I doubt anybody has tried it, so you'll have to experiment.

I imagine you could do it with a dracut module.  There is already a
module that will parse a pre-boot fstab (/etc/fstab.sys).  The trick
is that you need to create the root filesystem and the mountpoints
within it first.  The trick will be how dracut handles not specifying
a root filesystem.

However, if anything I think the future trend will be towards having
everything back on the root filesystem, since with btrfs you can set
quotas on subvolumes and have a lot more flexibility in general, which
you start to lose if you chop up your disks.  However, I guess you
could still have one big btrfs filesystem and mount individual
subvolumes out of it onto your root.  I'm not really sure what that
gets you.  Having the root itself be a subvolume does have benefits,
since you can then snapshot it and easily boot back off a snapshot if
something goes wrong.

Rich

[gentoo-dev] Re: udev <-> mdev

[Duncan]

Rich Freeman posted on Sat, 14 Jul 2012 19:57:41 -0400 as excerpted:

> On Sat, Jul 14, 2012 at 7:38 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>> BTW, any "gentooish" documentation out there on rootfs as tmpfs, with
>> /etc and the like mounted on top of it, operationally ro, rw remounted
>> for updates?
>>
>> That's obviously going to take an initr*, which I've never really
>> understood to the point I'm comfortable with my ability to recover from
>> problems so I've not run one since my Mandrake era, but that's a status
>> that can change, and what with the /usr move and some computer problems
>> I just finished dealing with, I've been thinking about the possibility
>> lately.  So if there's some good docs on the topic someone can point me
>> at, I'd be grateful. =:^)
> 
> I doubt anybody has tried it, so you'll have to experiment.

"Anybody" /anybody/, or "anybody" on gentoo?  FWIW, there are people 
running it in general (IIRC much of the discussion was on Debian, some on 
Fedora/RH), but I didn't see anything out there written from a gentoo 
perspective.  Gentoo-based docs/perspective does help, as one isn't 
constantly having to translate binary-based assumptions into "gentooese", 
but there's enough out there in general that a suitably determined/
motivated person at the usual experienced gentoo user level should be 
able to do it, without having to be an /extreme/ wizard.  But so far I've 
not been /that/ motivated, and if there was gentoo docs available, it 
would bring the barriers down far enough that I likely /would/ then have 
the (now lower) required motivation/determination.

Just looking for that shortcut, is all. =:^)

> I imagine you could do it with a dracut module.  There is already a
> module that will parse a pre-boot fstab (/etc/fstab.sys).  The trick is
> that you need to create the root filesystem and the mountpoints within
> it first.  The trick will be how dracut handles not specifying a root
> filesystem.

While I do know dracut is an initr* helper, you just made me quite aware 
of just how much research I'd have to do on the topic. =:^\   I wasn't 
aware dracut even /had/ modules, while you're referring to them with the 
ease of familiarity...

> However, if anything I think the future trend will be towards having
> everything back on the root filesystem, since with btrfs you can set
> quotas on subvolumes and have a lot more flexibility in general, which
> you start to lose if you chop up your disks.  However, I guess you could
> still have one big btrfs filesystem and mount individual subvolumes out
> of it onto your root.  I'm not really sure what that gets you.  Having
> the root itself be a subvolume does have benefits, since you can then
> snapshot it and easily boot back off a snapshot if something goes wrong.

The big problem with btrfs subvolumes from my perspective is that they're 
still all on a single primary filesystem, and if that filesystem develops 
problems... all your eggs/data are in one big basket, good luck if the 
bottom drops out of it!

One lesson I've had drilled into my head repeatedly over now two decades 
of computer experience... don't put all your data in one basket!  It's a 
personal policy that's saved my @$$ more than a few times over the years.

Even with raid, when I first setup md/raid, I set it up as a nice big 
(partitioned) raid, with a second (similarly partitioned) raid as a 
backup.  With triple-digits gigs of data (this was pre-terabyte-drive 
era), a system-crash related re-add and resync would take /hours/.  

So when I rebuilt the setup, I created over a dozen (including working 
and backup copies of many of them) individual raids, each in its own set 
of partitions on the physical devices, some raids of which were further 
partitioned, some not, but only the media raid (and its backup) were 
anything like 100 gigs, and with many of even the working raids (plus all 
backups) not even activated for normal operation unless I was actually 
working on whatever data was on that raid, and in general even most of 
the the assembled raids with rw mounting not actively writing at the time 
of a crash, re-add and resync tended to be seconds or minutes, not hours.

So I'm about as strong a partitioning-policy advocate as you'll get, tho 
I do keep everything that the pm installs, along with the installation 
database (so /etc, /usr, /var, but not for instance /var/log or /usr/src, 
which are mountpoints), on the same (currently) rootfs of 8-ish gigs, 
with a backup root partition (actually two of them now) that I can point 
the kernel at from grub, if the working rootfs breaks for some reason.  
So the separate /usr/ thing hasn't affected me at all, because /usr/ is 
on rootfs.

But as I said I had some computer hardware issues recently, and they made 
me aware of just how nice it'd be to have that rootfs mounted read-only 
for normal operation -- no fsck/log-replay needed on read-only-at-time-of-
crash mounts! =:^)

So I'm pondering just how hard it would be...

-- 
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: udev <-> mdev

[Rich Freeman]

On Sat, Jul 14, 2012 at 9:02 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Rich Freeman posted on Sat, 14 Jul 2012 19:57:41 -0400 as excerpted:
>>
>> I doubt anybody has tried it, so you'll have to experiment.
>
> "Anybody" /anybody/, or "anybody" on gentoo?  FWIW, there are people
> running it in general (IIRC much of the discussion was on Debian, some on
> Fedora/RH), but I didn't see anything out there written from a gentoo
> perspective.

I'd think that a source vs binary distro wouldn't matter much as far
as a tmpfs-based root goes.  That is, if you're taking about an empty
root that you just mount stuff on top of.

>> I imagine you could do it with a dracut module.  There is already a
>> module that will parse a pre-boot fstab (/etc/fstab.sys).  The trick is
>> that you need to create the root filesystem and the mountpoints within
>> it first.  The trick will be how dracut handles not specifying a root
>> filesystem.
>
> While I do know dracut is an initr* helper, you just made me quite aware
> of just how much research I'd have to do on the topic. =:^\   I wasn't
> aware dracut even /had/ modules, while you're referring to them with the
> ease of familiarity...

See:
http://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/

Much of dracut's power comes from its modules.  Again, I'm not sure
how it handles not being given a root at all.  You'd have to build a
root, or extract it from a tarball/etc.

Looking at the docs it seems like you'd need a hook for the cmdline
stage that sets rootok (assuming it gets that far without a root, or
if you set it to something like root=TMPFS).  Then you'd install a
hook to mount to mount the tmpfs, and then use the fstab-sys module to
mount everything else.  You'd need to create mountpoints for
everything of course, and not just the boot-critical stuff, since
otherwise openrc won't be able to finish mounting mounting everything.

>
> The big problem with btrfs subvolumes from my perspective is that they're
> still all on a single primary filesystem, and if that filesystem develops
> problems... all your eggs/data are in one big basket, good luck if the
> bottom drops out of it!

Maybe, but does it really buy you much if you only lose /lib, and not
/usr?  I guess it is less data to restore from backup, but...

The beauty of btrfs subvolumes is that it lets you manage all your
storage as a single pool, even more flexibly than LVM.  Sure, chopping
it up does reduce the impact of failure a bit, but I'd hate to have to
maintain such a system.  Filesystem failure should be a very rare
occurance for any decent filesystem (of course, this is why I won't be
using btrfs in production for a while).

Rich

[gentoo-dev] Re: udev <-> mdev

[Duncan]

Rich Freeman posted on Sun, 15 Jul 2012 08:30:31 -0400 as excerpted:

> Looking at the docs it seems like you'd need a hook for the cmdline
> stage that sets rootok (assuming it gets that far without a root, or if
> you set it to something like root=TMPFS).  Then you'd install a hook to
> mount to mount the tmpfs, and then use the fstab-sys module to mount
> everything else.  You'd need to create mountpoints for everything of
> course, and not just the boot-critical stuff, since otherwise openrc
> won't be able to finish mounting mounting everything.

The last bit I had already anticipated, as I'm doing something similar 
with my tmpfs-based /tmp and /var/tmp (symlinked to /tmp).  Nothing 
mounted on top, but I'm creating subdirs inside it, setting permissions, 
etc.  A critical difference is that this is on a full rootfs so I don't 
have to worry about not having the necessary tools available yet, but I 
do have the general ideas down.  And I'm doing some bind-mounts as well, 
which require a remount to let all the options take effect, and of course 
there's mount ordering to worry about, etc.  So I have the general idea, 
but doing it from an initr* with limited tools available will be 
interesting.

As for the tmpfs rootfs itself, I have the vague idea that I'd 
"simply" (note the scare-quotes) use what's normally the initial root 
that's essentially thrown away, only I'd not throw it away, I'd just 
mount everything on top, keep using it, and /somehow/ ensure that 
anything running from it directly terminates one way or another, so that 
I don't have old processes stuck around using the mounted-over points.
 
>> The big problem with btrfs subvolumes from my perspective is that
>> they're still all on a single primary filesystem, and if that
>> filesystem develops problems... all your eggs/data are in one big
>> basket, good luck if the bottom drops out of it!
> 
> Maybe, but does it really buy you much if you only lose /lib, and not
> /usr?  I guess it is less data to restore from backup, but...

Which is why I keep /usr (and /lib64 and /usr/lib64) on rootfs currently, 
tho the traditional /usr/src/, /usr/local, and /usr/portage are either 
pointed elsewhere with the appropriate vars or mountpoints/symlinks to 
elsewhere.  Of course that'd have to change a bit for a tmpfs rootfs, 
since /lib64, /usr and /etc would obviously be mounted from elsewhere, 
but they could still be either symlinked or bind-mounted to the 
appropriate location on the single (read-only) system-filesystem.

FWIW I remember being truly fascinated with the power of symlinks when I 
first switched from MS.  Now I consider them normal, but the power and 
flexibility of bind-mounts still amazes me, especially since, as with 
symlinks, it's possible to bind-mount individual files, but unlike 
symlinks (more like hard-links but cross-filesystem), it's possible to 
have some of the bind-mounts read-write (or dev, exec, etc) while others 
are read-only (or nodev, noexec...).

> The beauty of btrfs subvolumes is that it lets you manage all your
> storage as a single pool, even more flexibly than LVM.  Sure, chopping
> it up does reduce the impact of failure a bit, but I'd hate to have to
> maintain such a system.  Filesystem failure should be a very rare
> occurance for any decent filesystem (of course, this is why I won't be
> using btrfs in production for a while).

Very rare, yes.  Hardware issues happen tho.  I remember the a/c failing 
at one point, thus causing ambient temps (Phoenix summer) to reach 50C or 
so, and who knows how much in the computer.  Head-crash time.  But after 
cooling off, the unmounted-at-the-time filesystems were damaged very 
little, while a couple of the mounted filesystems surely had physical 
grooves in the platter.  Had that been all one filesystem, the damage 
would have been far less confined.  That's one example.

Another one, happened back when I was beta testing IE4 on MS, was due to 
a system software error on their part.  IE started bypassing the 
filesystem and writing to the cache index directly, but it wasn't set 
system attribute, so the defragger moved the file and put something else 
in that physical disk location.  I had my temp-inet-files on tmp, which 
was its own partition and didn't have significant issues, but some of the 
other betatesters lost valuable data, overwritten by IE, which was still 
bypassing the filesystem and writing directly to what it thought was its 
cache index file.

So it's not always filesystem failure, itself.  But I tried btrfs for a 
bit just to get an idea what it was all about, and agree totally with you 
there.  I'm off of it entirely now, and won't be touching it again until 
I'd guess early next year at the earliest.  The thing simply isn't ready 
for the expectations I have of my filesystems, and anybody using it now 
without backups is simply playing Russian Roulette with their data.

-- 
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: udev <-> mdev

[Rich Freeman]

On Sun, Jul 15, 2012 at 2:25 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> So I have the general idea,
> but doing it from an initr* with limited tools available will be
> interesting.
>

Dracut modules can specify any tools they need, and they will be
loaded into the initramfs.  Obviously you'll want to use some
discretion here.

> As for the tmpfs rootfs itself, I have the vague idea that I'd
> "simply" (note the scare-quotes) use what's normally the initial root
> that's essentially thrown away, only I'd not throw it away, I'd just
> mount everything on top, keep using it, and /somehow/ ensure that
> anything running from it directly terminates one way or another, so that
> I don't have old processes stuck around using the mounted-over points.

I suspect you could do that, but you'd probably have to change the
cleanup code, and you need to keep in mind that the initramfs runs on
ramfs and not tmpfs.  While similar there are a few important
differences.  Ramfs does not support size limits, so you can
extinguish all of your ram easily enough.  Ramfs also does not swap,
which means that any actual content in that filesystem will waste ram,
whether it is used or not.  Anything that writes to it could wipe out
all your memory even if you have swap available.  The design of ramfs
is designed for simplicity rather than robustness (you can support an
initramfs on a system that otherwise lacks the drivers for tmpfs.

> Which is why I keep /usr (and /lib64 and /usr/lib64) on rootfs currently,
> tho the traditional /usr/src/, /usr/local, and /usr/portage are either
> pointed elsewhere with the appropriate vars or mountpoints/symlinks to
> elsewhere.  Of course that'd have to change a bit for a tmpfs rootfs,
> since /lib64, /usr and /etc would obviously be mounted from elsewhere,
> but they could still be either symlinked or bind-mounted to the
> appropriate location on the single (read-only) system-filesystem.

Giving it a little thought, the simplest tmpfs-based root would be one
that defines a tarball as a the root.  The system would create a
tmpfs, extract the tarball to it, and then use the existing fstab-sys
module to mount stuff on top of that.  This gives you the option of
actually putting some content in the tarball, or just storing an empty
directory structure in it.  A tarball would let you set
permissions/etc and be a bit more generic than writing a custom
script.  If you wrote a module to do this I wouldn't be suprised if
upstream let you merge it.  You'd just need to define some kind of
sane syntax for it (root=TAR=path...to...tarball - though how a path
works with nothing mounted you'd have to define).  Maybe you define
the tarball at initramfs creation (as is done with fstab.sys and
mdadm.conf).

>
> FWIW I remember being truly fascinated with the power of symlinks when I
> first switched from MS.  Now I consider them normal, but the power and
> flexibility of bind-mounts still amazes me, especially since, as with
> symlinks, it's possible to bind-mount individual files, but unlike
> symlinks (more like hard-links but cross-filesystem), it's possible to
> have some of the bind-mounts read-write (or dev, exec, etc) while others
> are read-only (or nodev, noexec...).

Yup, my /usr and /var are bind-mounts - I was following the
pre-initramfs raid guide and had my root on a raid1, and wanted to
keep it minimal.  However, rather than having 47 individual
filesystems in lvm I only defined a few and bind-mounted half the tree
off of one of them.  Fstab.sys seems to handle that just fine
(mounting the main mountpoint first, and the bind mounts afterwards).

Rich

[gentoo-dev] Re: udev <-> mdev

[Duncan]

Rich Freeman posted on Sun, 15 Jul 2012 14:48:55 -0400 as excerpted:

> Giving it a little thought, the simplest tmpfs-based root would be one
> that defines a tarball as a the root.  The system would create a tmpfs,
> extract the tarball to it, and then use the existing fstab-sys module to
> mount stuff on top of that.  This gives you the option of actually
> putting some content in the tarball, or just storing an empty directory
> structure in it.  A tarball would let you set permissions/etc and be a
> bit more generic than writing a custom script.  If you wrote a module to
> do this I wouldn't be suprised if upstream let you merge it.  You'd just
> need to define some kind of sane syntax for it
> (root=TAR=path...to...tarball - though how a path works with nothing
> mounted you'd have to define).  Maybe you define the tarball at
> initramfs creation (as is done with fstab.sys and mdadm.conf).

Tarball is an interesting idea I hadn't considered.  At first blush I 
like it. =:^)

Thinking in that direction does stimulate yet another idea, tho.  What 
about a squashfs root?  AFAIK squashfs is read-only at use time, thus 
enforcing actually mounting something else to write anything, eliminating 
many of the down sides of sticking with the initial ramfs root, but it 
would allow the same flexibility in terms of sticking whatever into it at 
create-time, while only taking the memory necessary for what's actually 
stuck in it at create-time.  I /think/ it's swappable, too, which would 
give me some flexibility in terms of letting more stuff be added at 
create-time without having to worry about it being locked in memory.  And 
I think squashfs is reasonably tested territory for this sort of thing, 
given its use for live-media, etc.  And it's in mainline now, too, which 
is nice.  =:^)  I'll have to do some research and think about that a bit 
more...

Definitely thanks for the tarball idea, as otherwise I'd probably have 
not got out of my "box" and thought about squashfs.  I'm probably missing 
its downsides ATM, but you still broke my thinking out of the box!

-- 
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: udev <-> mdev

[Michael Mol]

On Sun, Jul 15, 2012 at 8:30 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Rich Freeman posted on Sun, 15 Jul 2012 14:48:55 -0400 as excerpted:
>
>> Giving it a little thought, the simplest tmpfs-based root would be one
>> that defines a tarball as a the root.  The system would create a tmpfs,
>> extract the tarball to it, and then use the existing fstab-sys module to
>> mount stuff on top of that.  This gives you the option of actually
>> putting some content in the tarball, or just storing an empty directory
>> structure in it.  A tarball would let you set permissions/etc and be a
>> bit more generic than writing a custom script.  If you wrote a module to
>> do this I wouldn't be suprised if upstream let you merge it.  You'd just
>> need to define some kind of sane syntax for it
>> (root=TAR=path...to...tarball - though how a path works with nothing
>> mounted you'd have to define).  Maybe you define the tarball at
>> initramfs creation (as is done with fstab.sys and mdadm.conf).
>
> Tarball is an interesting idea I hadn't considered.  At first blush I
> like it. =:^)
>
> Thinking in that direction does stimulate yet another idea, tho.  What
> about a squashfs root?  AFAIK squashfs is read-only at use time, thus
> enforcing actually mounting something else to write anything, eliminating
> many of the down sides of sticking with the initial ramfs root, but it
> would allow the same flexibility in terms of sticking whatever into it at
> create-time, while only taking the memory necessary for what's actually
> stuck in it at create-time.  I /think/ it's swappable, too, which would
> give me some flexibility in terms of letting more stuff be added at
> create-time without having to worry about it being locked in memory.  And
> I think squashfs is reasonably tested territory for this sort of thing,
> given its use for live-media, etc.  And it's in mainline now, too, which
> is nice.  =:^)  I'll have to do some research and think about that a bit
> more...
>
> Definitely thanks for the tarball idea, as otherwise I'd probably have
> not got out of my "box" and thought about squashfs.  I'm probably missing
> its downsides ATM, but you still broke my thinking out of the box!

This is sounding closer and closer to an on-disk liveCD.

-- 
:wq

[gentoo-dev] Re: udev <-> mdev

[Duncan]

Michael Mol posted on Sun, 15 Jul 2012 20:57:28 -0400 as excerpted:

> This is sounding closer and closer to an on-disk liveCD.

It is, isn't it?  But I'd want to keep it reasonably small, as I guess 
I'd be rebuilding the squashfs pretty much whenever I updated any package 
that it contained binaries from.

Actually, I guess if I did squashfs, I could even mount it directly, 
avoiding the initr* entirely, tho in effect it'd be close.  I could have 
the kernel call a shell script as init, then have it exec the real init 
(and thus openrc) after it did some initial setup and mounts, thus 
allowing the real init to inherit the same PID 1 it normally gets.  (Some 
of that idea is triggered by Maxim K's post.  Thanks to both of you.)

Alternatively, I could reconfigure inittab to start my script first, then 
start openrc (consolidating the openrc sysinit, etc, entries).  But that 
actually sounds more complex than simply running an initial script as 
init, and having it exec init.

-- 
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: udev <-> mdev

[Peter Stuge]

Duncan wrote:
> Alternatively, I could reconfigure inittab to start my script first
..
> that actually sounds more complex

Use init. It would be a sensitive script. If it fails the kernel is sad.


//Peter

Re: [gentoo-dev] Re: udev <-> mdev

[Maxim Kammerer]

On Mon, Jul 16, 2012 at 3:30 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Thinking in that direction does stimulate yet another idea, tho.  What
> about a squashfs root?  AFAIK squashfs is read-only at use time, thus
> enforcing actually mounting something else to write anything, eliminating
> many of the down sides of sticking with the initial ramfs root, but it
> would allow the same flexibility in terms of sticking whatever into it at
> create-time, while only taking the memory necessary for what's actually
> stuck in it at create-time.

It is possible, see:
https://github.com/mkdesu/liberte/blob/master/src/root/initrd/init
https://github.com/mkdesu/liberte/blob/master/src/etc/fstab

The setup above is somewhat different from what you have in mind
(SquashFS image is located on disk, and contains the complete live
filesystem, not just a skeleton), so mounting read-writable branches
can be deferred to the regular post-initramfs services (such as
localmount) — on the other hand, maybe you want to do the same (mount
branches read-only in initramfs, and remount them read-write in an
init.d service).

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] Re: udev <-> mdev

[Ian Stakenvicius]

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

On 15/07/12 09:00 PM, Maxim Kammerer wrote:
> On Mon, Jul 16, 2012 at 3:30 AM, Duncan <1i5t5.duncan@cox.net>
> wrote:
>> Thinking in that direction does stimulate yet another idea, tho.
>> What about a squashfs root?  AFAIK squashfs is read-only at use
>> time, thus enforcing actually mounting something else to write
>> anything, eliminating many of the down sides of sticking with the
>> initial ramfs root, but it would allow the same flexibility in
>> terms of sticking whatever into it at create-time, while only
>> taking the memory necessary for what's actually stuck in it at
>> create-time.
> 
> It is possible, see: 
> https://github.com/mkdesu/liberte/blob/master/src/root/initrd/init 
> https://github.com/mkdesu/liberte/blob/master/src/etc/fstab
> 
> The setup above is somewhat different from what you have in mind 
> (SquashFS image is located on disk, and contains the complete live 
> filesystem, not just a skeleton), so mounting read-writable
> branches can be deferred to the regular post-initramfs services
> (such as localmount) — on the other hand, maybe you want to do the
> same (mount branches read-only in initramfs, and remount them
> read-write in an init.d service).
> 

...if going this route, why not simply not bother to pivot_root out of
the initramfs at all?  or pivot_root but only into a directory
structure still sitting in the initramfs?  As long as all non-root
bits are in separate storage, you can mount 'em all in the appropriate
place...


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

iF4EAREIAAYFAlAEHNAACgkQ2ugaI38ACPCbBgD+MCInpuQXjir37zFTn3ebJe30
dEWqqxihYox1+XrR7JYA/26jjkglGXZzxP0Kq17xuyoDBD8qnymAsziieDsMCMvN
=/C5P
-----END PGP SIGNATURE-----

[gentoo-dev] Re: udev <-> mdev

[Duncan]

Ian Stakenvicius posted on Mon, 16 Jul 2012 09:53:20 -0400 as excerpted:

> ...if going this route, why not simply not bother to pivot_root out of
> the initramfs at all?  or pivot_root but only into a directory structure
> still sitting in the initramfs?  As long as all non-root bits are in
> separate storage, you can mount 'em all in the appropriate place...

I'm not sure whether that was asked of me or Maxim K, but that was 
beginning to be my conclusion as well.  See the earlier comment about not 
even using an initr* at all, "tho this would be close".

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

[gentoo-dev] Re: udev <-> mdev

[Nicolas Sebrecht]

The 13/07/12, William Hubbs wrote:

> What about using devtmpfs alone?

It's quiet fine for very simple systems.

-- 
Nicolas Sebrecht

Re: [gentoo-dev] Re: udev <-> mdev

[Graham Murray]

"Walter Dnes" <waltdnes@waltdnes.org> writes:

> On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
>> On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao <ryao@gentoo.org> wrote:
>> > mdev would need to switch to the netlink hotplug interface.
>> 
>> I think that's quite unlikely, since mdev is not a daemon. Perhaps by
>> the time /proc/sys/kernel/hotplug is gone, mdev advocates will have
>> settled on some early udev fork. [1]
>
>   Do you realize this would effectively kill linux in the embedded
> device area?  Udev, even without the systemd code, is simply to large
> for embedded devices.

But surely most embedded devices do not need hotplug functionality, they
have a known, fixed, set of devices. So should static nodes in /dev/ not
be sufficient?

[gentoo-dev] Re: udev <-> mdev

[Duncan]

Graham Murray posted on Sat, 14 Jul 2012 07:13:56 +0100 as excerpted:

> "Walter Dnes" <waltdnes@waltdnes.org> writes:
> 
>>   Do you realize this would effectively kill linux in the embedded
>> device area?  Udev, even without the systemd code, is simply to large
>> for embedded devices.
> 
> But surely most embedded devices do not need hotplug functionality, they
> have a known, fixed, set of devices. So should static nodes in /dev/ not
> be sufficient?

Well, there's (kernel-side) devfs as well, as others have mentioned. 

Meanwhile, "embedded" can mean different things to different users of the 
term.  I expect few would argue that onboard boot devices on embedded are 
likely to change, but there's a lot of (arguably embedded) devices with 
USB-host support these days, and some form of dynamic device-nodes, even 
if it's just devfs, can make that much more flexible and easier to deal 
with.

What's interesting is the potential on such devices for USB-based 
storage, displays, sound, net and HID, blurring the definition of 
"embedded" even further, altho one would hope nobody tries to connect all 
of those up to the same host USB port (via hub) at the same time as I can 
just imagine the bandwidth management headaches trying to do so, thus 
implying 2-3 USB host-ports, minimum.

-- 
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: udev <-> mdev

[Walter Dnes]

On Fri, Jul 13, 2012 at 05:58:25AM +0000, Duncan wrote

> They're seriously thinking about (and may be planning on) removing
> that option from the kernel entirely, to keep people configuring
> their first kernels from getting themselves in trouble, but of
> course that's now part of the kernel/userspace interface, so it
> isn't allowed to just disappear like kernel/kernel interfaces can.

  A couple of points...
1) Your "argument" applies to just about anything in the kernel
configuration process.  If you don't follow instructions, the kernel
will encounter anything from partial loss of functionality to possibly
failing to boot at all.  I'm a big boy.  If I foul up, I'll admit that I
goofed.

2) Full disclosure; I do have an interest in retaining the hotplug
pointer mechanism.  I have mdev set up on my machines as per
https://wiki.gentoo.org/wiki/Mdev

  Going one step further, I have auto(un)mount working on my machines
as per https://wiki.gentoo.org/wiki/Mdev/Automount_USB and
https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount  This has been
working OK for me for a few weeks, and I've asked others to test on
their machines.  I'll still consider it beta (Work In Progress) until
other people confirm it works for them.  Once that's done, my next
project might be "custom mdev rules", similar to "custom udev rules".

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] RFC: virtual/libudev

[Michał Górny]

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

On Tue, 10 Jul 2012 21:23:39 +0200
Thomas Sachau <tommy@gentoo.org> wrote:

> Michał Górny schrieb:
> > Hello, all.
> > 
> > Since nowadays udev is bundled within systemd, we start having two
> > libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
> > the long story short, I would like to introduce a virtual for
> > libudev which would pull in either of those two.
> > 
> > There are three USE flags used in conditionals when depending on
> > udev:
> > - gudev - for glib wrapper on udev,
> > - hwdb - to pull in hwids,
> > - static-libs.
> > 
> > The former two were previously provided by 'extras' USE flag,
> > and the third was unconditional.
> > 
> > I'm attaching an example virtual/libudev which does the job. Sadly,
> > because of the 'extras' compatibility it's a big ugly conditional.
> > 
> > An alternative would be to provide separate virtual/libudev
> > and virtual/libgudev; and maybe changing ebuilds not to depend on
> > [hwids] but rather pull in sys-apps/hwids directly (since that's
> > what the flag does).
> > 
> > What are you thoughts?
> 
> As discussed on IRC, there is still no consensus for installing the
> udev files with systemd, which is the beginning for the block and the
> virtual. So we should first sort that point out, before we even start
> to think about an ebuild for an udev virtual.

Do you have a technical or policy reason prohibiting me from maintaining
a systemd ebuild following the upstream policies?

> So for now: A clear no, i am against adding a virtual/libudev ebuild.

Please give the rationale.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: virtual/libudev

[Rich Freeman]

On Wed, Jul 11, 2012 at 10:09 AM, Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 10 Jul 2012 21:23:39 +0200
> Thomas Sachau <tommy@gentoo.org> wrote:
>> As discussed on IRC, there is still no consensus for installing the
>> udev files with systemd, which is the beginning for the block and the
>> virtual. So we should first sort that point out, before we even start
>> to think about an ebuild for an udev virtual.
>
> Do you have a technical or policy reason prohibiting me from maintaining
> a systemd ebuild following the upstream policies?
>

It sounds like we have two packages that COULD provide udev - udev and
systemd.  If we decide for both of them to provide udev then we need a
virtual and they need to block (which should make switching more fun).
 If we decide to keep using the udev package to install udev then we
don't need a virtual.

I'd view this like the split kde ebuilds.  Upstream ships a monster
tarball, and we install it in chunks.  Just because upstream ships
both packages together doesn't require us to install them together.
From a code-reuse standpoint and ease of transition standpoint it
makes sense to keep them split, as long as we can have everybody
continue to use the same udev codebase.

Rich

Re: [gentoo-dev] RFC: virtual/libudev

[Michał Górny]

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

On Wed, 11 Jul 2012 10:35:32 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Wed, Jul 11, 2012 at 10:09 AM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > On Tue, 10 Jul 2012 21:23:39 +0200
> > Thomas Sachau <tommy@gentoo.org> wrote:
> >> As discussed on IRC, there is still no consensus for installing the
> >> udev files with systemd, which is the beginning for the block and
> >> the virtual. So we should first sort that point out, before we
> >> even start to think about an ebuild for an udev virtual.
> >
> > Do you have a technical or policy reason prohibiting me from
> > maintaining a systemd ebuild following the upstream policies?
> >
> 
> It sounds like we have two packages that COULD provide udev - udev and
> systemd.  If we decide for both of them to provide udev then we need a
> virtual and they need to block (which should make switching more fun).
>  If we decide to keep using the udev package to install udev then we
> don't need a virtual.

No, switching is no fun. It's plain simple with weak blockers. It's
even their purpose.
 
> I'd view this like the split kde ebuilds.  Upstream ships a monster
> tarball, and we install it in chunks.  Just because upstream ships
> both packages together doesn't require us to install them together.
> From a code-reuse standpoint and ease of transition standpoint it
> makes sense to keep them split, as long as we can have everybody
> continue to use the same udev codebase.

Are you aware how much additional code and maintenance does keeping two
hacked build systems introduce? One of things I don't want to do is
keeping the list of *all other* systemd targets up-to-date,
and installing them all by hand.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: virtual/libudev

[Rich Freeman]

On Wed, Jul 11, 2012 at 10:52 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Are you aware how much additional code and maintenance does keeping two
> hacked build systems introduce? One of things I don't want to do is
> keeping the list of *all other* systemd targets up-to-date,
> and installing them all by hand.

I'd assumed that Thomas was representing some lack of consensus among
the systemd team.  If the systemd team really is aligned with wanting
to install udev within their build then the virtual makes sense to me.
 It would have no impact on other packages and would make things
easier for systemd.

That said, we need to keep an eye on any continuing drift between udev
and our needs.  If there is a fork and one does the /usr move then we
need to figure out some way of handling that.

Just seems like part of the continuing "Androidification" of Linux.
It really is the year of the linux desktop (or phone), but linux only
in the sense of the kernel that is being run.  Between the /usr move,
systemd, upstart, wayland, unity, GnomeOS, udev, and who knows what is
next, it seems like we're going to end up with 20 medium-sized distros
and no piece of code runs reliably on more than one or two of them.
Linux will end up having less in common with itself than it currently
has in common with Solaris.

Rich

Re: [gentoo-dev] RFC: virtual/libudev

[Thomas Sachau]

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

Michał Górny schrieb:
> On Tue, 10 Jul 2012 21:23:39 +0200
> Thomas Sachau <tommy@gentoo.org> wrote:
> 
>> Michał Górny schrieb:
>>> Hello, all.
>>>
>>> Since nowadays udev is bundled within systemd, we start having two
>>> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
>>> the long story short, I would like to introduce a virtual for
>>> libudev which would pull in either of those two.
>>>
>>> There are three USE flags used in conditionals when depending on
>>> udev:
>>> - gudev - for glib wrapper on udev,
>>> - hwdb - to pull in hwids,
>>> - static-libs.
>>>
>>> The former two were previously provided by 'extras' USE flag,
>>> and the third was unconditional.
>>>
>>> I'm attaching an example virtual/libudev which does the job. Sadly,
>>> because of the 'extras' compatibility it's a big ugly conditional.
>>>
>>> An alternative would be to provide separate virtual/libudev
>>> and virtual/libgudev; and maybe changing ebuilds not to depend on
>>> [hwids] but rather pull in sys-apps/hwids directly (since that's
>>> what the flag does).
>>>
>>> What are you thoughts?
>>
>> As discussed on IRC, there is still no consensus for installing the
>> udev files with systemd, which is the beginning for the block and the
>> virtual. So we should first sort that point out, before we even start
>> to think about an ebuild for an udev virtual.
> 
> Do you have a technical or policy reason prohibiting me from maintaining
> a systemd ebuild following the upstream policies?

How about this simple one: The udev ebuild does already install udev, so
why should we have another package also installing the same thing,
resulting in a blocker, the need to switch from one package to another
and the need for package maintainers to switch their dependencies?

Since William already said, that he will move the udev installation to
/usr/lib, i dont see any technical reason left to not simply depend on
the udev ebuild.
And if you fear issues about not knowing which parts to install, then
just check the files installed by the udev ebuild, remove them from your
systemd ebuild and you are done.
> 
>> So for now: A clear no, i am against adding a virtual/libudev ebuild.
> 
> Please give the rationale.

I did above. So if you still want to install udev yourself, please give
the rationale for doing so. And neither upstream naming nor a big
upstream tarball nor the Makefile do force this, so please exclude those
points.


-- 

Thomas Sachau
Gentoo Linux Developer




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

Re: [gentoo-dev] RFC: virtual/libudev

[Mike Gilbert]

On Wed, Jul 11, 2012 at 2:26 PM, Thomas Sachau <tommy@gentoo.org> wrote:
> Michał Górny schrieb:
>> On Tue, 10 Jul 2012 21:23:39 +0200
>> Thomas Sachau <tommy@gentoo.org> wrote:
>>
>>> Michał Górny schrieb:
>>>> Hello, all.
>>>>
>>>> Since nowadays udev is bundled within systemd, we start having two
>>>> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
>>>> the long story short, I would like to introduce a virtual for
>>>> libudev which would pull in either of those two.
>>>>
>>>> There are three USE flags used in conditionals when depending on
>>>> udev:
>>>> - gudev - for glib wrapper on udev,
>>>> - hwdb - to pull in hwids,
>>>> - static-libs.
>>>>
>>>> The former two were previously provided by 'extras' USE flag,
>>>> and the third was unconditional.
>>>>
>>>> I'm attaching an example virtual/libudev which does the job. Sadly,
>>>> because of the 'extras' compatibility it's a big ugly conditional.
>>>>
>>>> An alternative would be to provide separate virtual/libudev
>>>> and virtual/libgudev; and maybe changing ebuilds not to depend on
>>>> [hwids] but rather pull in sys-apps/hwids directly (since that's
>>>> what the flag does).
>>>>
>>>> What are you thoughts?
>>>
>>> As discussed on IRC, there is still no consensus for installing the
>>> udev files with systemd, which is the beginning for the block and the
>>> virtual. So we should first sort that point out, before we even start
>>> to think about an ebuild for an udev virtual.
>>
>> Do you have a technical or policy reason prohibiting me from maintaining
>> a systemd ebuild following the upstream policies?
>
> How about this simple one: The udev ebuild does already install udev, so
> why should we have another package also installing the same thing,
> resulting in a blocker, the need to switch from one package to another
> and the need for package maintainers to switch their dependencies?

Just to put a number to this, there are currently 126 packages in the
tree with a dependency on sys-fs/udev.

> Since William already said, that he will move the udev installation to
> /usr/lib, i dont see any technical reason left to not simply depend on
> the udev ebuild.
> And if you fear issues about not knowing which parts to install, then
> just check the files installed by the udev ebuild, remove them from your
> systemd ebuild and you are done.

This means that systemd users end up building the udev components
twice, and throwing away the second copy. You don't seem to care about
this, but I think it is a valid concern.

I am guessing that systemd is or will become very sensitive to any
change in udev's API, so each systemd version would have to depend
exactly on the corresponding udev version. This means that a systemd
version bump could be stuck waiting on the corresponding udev version.

I also wonder if incompatibilities may be introduced by passing
different build options in the udev and systemd ebuilds due to having
different use flags enabled, for example. This can be worked around
with use-deps of course, but it is yet another pain point for the
systemd maintainer.

If there were a way to tell the systemd build system to build against
the "system udev", that might avoid the issue, but I doubt systemd
upstream would implement such a thing.

Personally, I think a consolidated systemd/udev package is the best
way to go here. Short of that, the virtual + blockers seems like an
acceptable solution.

Re: [gentoo-dev] RFC: virtual/libudev

[William Hubbs]

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

On Wed, Jul 11, 2012 at 03:27:41PM -0400, Mike Gilbert wrote:
> Just to put a number to this, there are currently 126 packages in the
> tree with a dependency on sys-fs/udev.
> 
> Personally, I think a consolidated systemd/udev package is the best
> way to go here. Short of that, the virtual + blockers seems like an
> acceptable solution.

Thinking on this, I agree with Mike here, and to make it easier for
maintainers so they don't have to change their dependencies, it should
be a udev ebuild with a systemd use flag.

William


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

Re: [gentoo-dev] RFC: virtual/libudev

[Mike Gilbert]

On Wed, Jul 11, 2012 at 3:54 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Wed, Jul 11, 2012 at 03:27:41PM -0400, Mike Gilbert wrote:
>> Just to put a number to this, there are currently 126 packages in the
>> tree with a dependency on sys-fs/udev.
>>
>> Personally, I think a consolidated systemd/udev package is the best
>> way to go here. Short of that, the virtual + blockers seems like an
>> acceptable solution.
>
> Thinking on this, I agree with Mike here, and to make it easier for
> maintainers so they don't have to change their dependencies, it should
> be a udev ebuild with a systemd use flag.
>

An alternative to the funky udev[systemd] solution would be to replace
the entire udev ebuild with RDEPEND="sys-apps/systemd", and implement
the requisite logic in the systemd ebuild. This would effectively make
udev a virtual package without the need to modify any other packages.

Re: [gentoo-dev] RFC: virtual/libudev

[William Hubbs]

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

On Wed, Jul 11, 2012 at 04:33:44PM -0400, Mike Gilbert wrote:
> On Wed, Jul 11, 2012 at 3:54 PM, William Hubbs <williamh@gentoo.org> wrote:
> > Thinking on this, I agree with Mike here, and to make it easier for
> > maintainers so they don't have to change their dependencies, it should
> > be a udev ebuild with a systemd use flag.
> 
> An alternative to the funky udev[systemd] solution would be to replace
> the entire udev ebuild with RDEPEND="sys-apps/systemd", and implement
> the requisite logic in the systemd ebuild. This would effectively make
> udev a virtual package without the need to modify any other packages.

You would still have funkey logic in the systemd ebuild then, because
you would have to have a use flag, maybe "udev-standalone"
which would make it only install udev, and you would still have to deal
with use flags that don't make sense without systemd being installed.

William


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

Re: [gentoo-dev] RFC: virtual/libudev

[vivo75]

Il 11/07/2012 22:33, Mike Gilbert ha scritto:
> On Wed, Jul 11, 2012 at 3:54 PM, William Hubbs<williamh@gentoo.org>  wrote:
>> On Wed, Jul 11, 2012 at 03:27:41PM -0400, Mike Gilbert wrote:
>>> Just to put a number to this, there are currently 126 packages in the
>>> tree with a dependency on sys-fs/udev.
>>>
>>> Personally, I think a consolidated systemd/udev package is the best
>>> way to go here. Short of that, the virtual + blockers seems like an
>>> acceptable solution.
>> Thinking on this, I agree with Mike here, and to make it easier for
>> maintainers so they don't have to change their dependencies, it should
>> be a udev ebuild with a systemd use flag.
>>
> An alternative to the funky udev[systemd] solution would be to replace
> the entire udev ebuild with RDEPEND="sys-apps/systemd", and implement
> the requisite logic in the systemd ebuild. This would effectively make
> udev a virtual package without the need to modify any other packages.
Long time ago portage managed virtual/* ebuilds differently from the 
others, it may be wise to ask to the portage developers if that's still 
the case and why/what is done.

Re: [gentoo-dev] RFC: virtual/libudev

[Michał Górny]

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

On Wed, 11 Jul 2012 15:27:41 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> Personally, I think a consolidated systemd/udev package is the best
> way to go here.

A consolidated package means that:

- every change made by udev developers would have to be reviewed by
  systemd team to make sure it doesn't break systemd. udev developers
  don't use systemd;
- every change made by systemd developers would have to be reviewed by
  udev team to make sure it doesn't break openrc. systemd developers
  usually don't run openrc;
- udev developers will force me to use eclasses they like and force
  their coding style on me;
- i will force eclasses I like and my coding style on udev developers;
- new udev wouldn't be able to be stabilized without systemd being
  stabilized at the same time (and I don't really think systemd is in
  any condition to go stable),
- there will be a few random flags which will either work or not,
  depending on a state of magical switch flag,
- and after all, the ebuild will be basically one big use-conditional.


-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: virtual/libudev

[Peter Alfredsen]

On Wed, Jul 11, 2012 at 11:04 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Wed, 11 Jul 2012 15:27:41 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>
>> Personally, I think a consolidated systemd/udev package is the best
>> way to go here.
>
> A consolidated package means that:
>
> - every change made by udev developers would have to be reviewed by
>   systemd team to make sure it doesn't break systemd. udev developers
>   don't use systemd;
> - every change made by systemd developers would have to be reviewed by
>   udev team to make sure it doesn't break openrc. systemd developers
>   usually don't run openrc;
> - udev developers will force me to use eclasses they like and force
>   their coding style on me;
> - i will force eclasses I like and my coding style on udev developers;
> - new udev wouldn't be able to be stabilized without systemd being
>   stabilized at the same time (and I don't really think systemd is in
>   any condition to go stable),
> - there will be a few random flags which will either work or not,
>   depending on a state of magical switch flag,
> - and after all, the ebuild will be basically one big use-conditional.

So, since this is blocking up development and people actually solving
things, could we just have virtual/udev and be done with it? Upstream
obviously reneged on their promise to make the component parts
buildable separately, so the virtual seems like the only sane choice
right now.

/Peter

Re: [gentoo-dev] RFC: virtual/libudev

[Canek Peláez Valdés]

On Thu, Jul 26, 2012 at 4:44 PM, Peter Alfredsen
<peter.alfredsen@gmail.com> wrote:
> On Wed, Jul 11, 2012 at 11:04 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> On Wed, 11 Jul 2012 15:27:41 -0400
>> Mike Gilbert <floppym@gentoo.org> wrote:
>>
>>> Personally, I think a consolidated systemd/udev package is the best
>>> way to go here.
>>
>> A consolidated package means that:
>>
>> - every change made by udev developers would have to be reviewed by
>>   systemd team to make sure it doesn't break systemd. udev developers
>>   don't use systemd;
>> - every change made by systemd developers would have to be reviewed by
>>   udev team to make sure it doesn't break openrc. systemd developers
>>   usually don't run openrc;
>> - udev developers will force me to use eclasses they like and force
>>   their coding style on me;
>> - i will force eclasses I like and my coding style on udev developers;
>> - new udev wouldn't be able to be stabilized without systemd being
>>   stabilized at the same time (and I don't really think systemd is in
>>   any condition to go stable),
>> - there will be a few random flags which will either work or not,
>>   depending on a state of magical switch flag,
>> - and after all, the ebuild will be basically one big use-conditional.
>
> So, since this is blocking up development and people actually solving
> things, could we just have virtual/udev and be done with it? Upstream
> obviously reneged on their promise to make the component parts
> buildable separately, so the virtual seems like the only sane choice
> right now.

Just to clarify, udev/systemd never promised "to make the component
parts buildable separately". They promised:

"we will be supporting this for a long time since it is a necessity to
make initrds (which lack systemd) work properly. Distributions not
wishing to adopt systemd can build udev pretty much the same way as
before, however should then use the systemd tarball instead of the
udev tarball and package only what is necessary of the resulting
build."

Where "package only what is necessary" being the important part for Gentoo.

http://lwn.net/Articles/490413/

Certainly they don't care about source-based distributions like
Gentoo, but they never promised "to make the component parts buildable
separately".

Anyway, I also support the virtual/udev, since it's the only way for
us systemd users to not build udev twice.

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

[gentoo-dev] Re: RFC: virtual/libudev

[Duncan]

Canek Peláez Valdés posted on Thu, 26 Jul 2012 17:08:35 -0500 as
excerpted:

> Just to clarify, udev/systemd never promised "to make the component
> parts buildable separately". They promised:
> 
> "we will be supporting this for a long time since it is a necessity to
> make initrds (which lack systemd) work properly. Distributions not
> wishing to adopt systemd can build udev pretty much the same way as
> before, however should then use the systemd tarball instead of the udev
> tarball and package only what is necessary of the resulting build."
> 
> Where "package only what is necessary" being the important part for
> Gentoo.
> 
> http://lwn.net/Articles/490413/
> 
> Certainly they don't care about source-based distributions like Gentoo,
> but they never promised "to make the component parts buildable
> separately".
> 
> Anyway, I also support the virtual/udev, since it's the only way for us
> systemd users to not build udev twice.

Actually, they did.

1) It's no secret that gentoo is build-from-source.

2) It's no secret that gentoo is in the "distributions not wishing to 
adopt systemd" class, at this point at least.

3) Gentoo's not a tiny micro-distribution, nor one based on some other 
distribution.  Some may argue that gentoo and its ecosystem aren't Debian 
or Fedora-class, but it's certainly not too tiny to be considered a 
viable candidate for that "distributions not wishing..." class, which 
it's known to be in.

4) They promised, based on your quote: "can build udev pretty much the 
same way as before, however should then use the systemd tarball [...] and 
package only what is necessary."

5) Building the same as before does *NOT* include building systemd.

6) "Package", in the gentoo context, includes building, so ESPECIALLY 
given the promise to "build udev pretty much the same as before", they 
DID promise that udev would be buildable separately.

7) What they specifically did NOT promise, in fact, quite to the 
contrary, was that it would be TARBALLed separately, which isn't a huge 
deal for gentoo, which already has whole desktops (kde) splitting 
individual packages out of monolithic combined tarballs.

8) The only way around that is if they try to argue point #3, saying 
gentoo and its ecosystem is /indeed/ too small to be included in the 
definition of "distributions".

9) Otherwise, at very minimum, they're failing the "build udev pretty 
much the same as before" clause, if there's no provision within the 
tarball (such as separate make targets and source directories, with the 
systemd target not a dependency of udev target) to extract and build only 
udev, without building systemd as well.



Not that such promises hold much credibility anyway... see the kde 
promise (from Aaron S when he was president of KDE e.v. so as credible a 
spokesperson as it gets) continued kde3 support as long as there were 
users.  (AFAIK, at least gnome didn't make /that/ sort of promise in the 
leadup to gnome3.  And no, AS cannot be properly argued to have been 
referring to others, like debian with its slow release cycles, as he was 
president of kde ev, not president of debian, or of the trinity project, 
which AFAIK didn't even exist at the time, and didn't specify support 
from OTHERS, not kde, so he was clearly speaking for kde, not for other 
entities.)

-- 
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: RFC: virtual/libudev

[Canek Peláez Valdés]

On Thu, Jul 26, 2012 at 9:37 PM, Duncan <1i5t5.duncan@cox.net> wrote:
[ snip ]
> 9) Otherwise, at very minimum, they're failing the "build udev pretty
> much the same as before"

./configure
make
make install

You fail to see the matter from their POV. They don't care (that much)
about building, because the distributions they care about use binary
prebuilt packages. In that sense, "build udev pretty much the same as
before" is the holly trinity of "./configure; make; make install".
Otherwise the part about "package only what is necessary" has not that
much sense.

Which again leads to the "please, add a virtual/udev" so the people
using systemd don't need to built udev twice.

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] Re: RFC: virtual/libudev

[William Hubbs]

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

On Thu, Jul 26, 2012 at 09:49:04PM -0500, Canek Peláez Valdés wrote:
> On Thu, Jul 26, 2012 at 9:37 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> [ snip ]
> > 9) Otherwise, at very minimum, they're failing the "build udev pretty
> > much the same as before"
> 
> ./configure
> make
> make install
> 
> You fail to see the matter from their POV. They don't care (that much)
> about building, because the distributions they care about use binary
> prebuilt packages. In that sense, "build udev pretty much the same as
> before" is the holly trinity of "./configure; make; make install".
> Otherwise the part about "package only what is necessary" has not that
> much sense.
> 
> Which again leads to the "please, add a virtual/udev" so the people
> using systemd don't need to built udev twice.

Unless we add sys-apps/systemd to virtual/dev-manager.
If we do that I don't see a need for virtual/udev.

Also, I don't see how systemd users are building udev twice as it
currently stands.

William

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

Re: [gentoo-dev] Re: RFC: virtual/libudev

[Roy Bamford]

On 2012.07.27 03:37, Duncan wrote:
[snip]
> 
> Not that such promises hold much credibility anyway... see the kde 
> promise (from Aaron S when he was president of KDE e.v. so as 
> credible a  spokesperson as it gets) continued kde3 support as long 
> as there were 
> users.  (AFAIK, at least gnome didn't make /that/ sort of promise in
> the leadup to gnome3.  And no, AS cannot be properly argued to have 
> been 
> referring to others, like debian with its slow release cycles, as he
> was 
> president of kde ev, not president of debian, or of the trinity
> project, 
> which AFAIK didn't even exist at the time, and didn't specify support 
> from OTHERS, not kde, so he was clearly speaking for kde, not for
> other 
> entities.)
> 
> -- 
> 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
> 
> 
Duncan,

You don't want to listen to Presidents too much.  Look at other real 
life examples.  

Would you claim that the President of the Gentoo Foundation speaks for 
Gentoo? 


-- 
Regards,

Roy Bamford
(Neddyseagoon)

Gentoo Foundation Inc. (President)

[gentoo-dev] Re: RFC: virtual/libudev

[Duncan]

Roy Bamford posted on Sat, 28 Jul 2012 17:51:47 +0100 as excerpted:

> You don't want to listen to Presidents too much.  Look at other real
> life examples.
> 
> Would you claim that the President of the Gentoo Foundation speaks for
> Gentoo?

If he were making claims of that nature, yes, barring information to the 
contrary, I'd assume he had authority/authorization to do so, and would 
definitely hold gentoo to a responsibility to either follow thru or 
remove him for cause for making such claims without authorization to do 
so (or at very minimum, to publicly repudiate the claims if they didn't 
intend to follow thru).  If none of that happened, I'd blame gentoo even 
more than the spokesperson that made the claim, without public 
repudiation.

You're right, they're PR people and as such, their claims must 
(unfortunately)  be taken with a grain of salt.  But that doesn't 
eliminate the responsibility of whatever organization to either follow 
thru or repudiate, as it's the reputation and credibility of that 
organization on the line if they don't.

-- 
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: RFC: virtual/libudev

[Peter Stuge]

Duncan wrote:
> the responsibility of whatever organization to either follow 
> thru or repudiate, as it's the reputation and credibility of
> that organization on the line if they don't.

I think it's unreasonable to expect any third party to accept
responsibility for a receiver which is over-trusting a sender.

Receivers must be intelligent and diligent to not be fooled by
ignorant or outright malicious senders.

See also
http://en.wikipedia.org/wiki/The_War_of_the_Worlds_(radio_drama)

Society chose to make radio senders responsible by law. It's why
there are jingles. As with any free speech medium, that is not so
easy to enforce on the internet.

Just like you don't want to over-trust the guy on the corner dressed
up as a person of authority trying to disseminate whatever racist
propaganda you don't want to believe everything on the internet.

More than anything, please consider that what you have been told may
simply be a lie, and be prepared to rewind and re-evaluate the world
if you learn that this is the case. You may look like a fool for
believing someone who was telling a lie, but you'll look like a hero
for admitting that it happened and that you've learned something new.


//Peter

Re: [gentoo-dev] RFC: virtual/libudev

[William Hubbs]

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

On Tue, Jul 10, 2012 at 05:18:00PM +0200, Michał Górny wrote:
> Hello, all.
> 
> Since nowadays udev is bundled within systemd, we start having two
> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
> the long story short, I would like to introduce a virtual for libudev
> which would pull in either of those two.
> 
> There are three USE flags used in conditionals when depending on udev:
> - gudev - for glib wrapper on udev,
> - hwdb - to pull in hwids,
> - static-libs.
> 
> The former two were previously provided by 'extras' USE flag,
> and the third was unconditional.
> 
> I'm attaching an example virtual/libudev which does the job. Sadly,
> because of the 'extras' compatibility it's a big ugly conditional.

I'm going to ask here, because of the discussion on IRC, that you not
commit this yet. There are issues still we need to work out wrt
packaging systemd and udev.

William


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

Re: [gentoo-dev] RFC: virtual/libudev

[Michał Górny]

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

On Tue, 10 Jul 2012 14:24:27 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Tue, Jul 10, 2012 at 05:18:00PM +0200, Michał Górny wrote:
> > Hello, all.
> > 
> > Since nowadays udev is bundled within systemd, we start having two
> > libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
> > the long story short, I would like to introduce a virtual for
> > libudev which would pull in either of those two.
> > 
> > There are three USE flags used in conditionals when depending on
> > udev:
> > - gudev - for glib wrapper on udev,
> > - hwdb - to pull in hwids,
> > - static-libs.
> > 
> > The former two were previously provided by 'extras' USE flag,
> > and the third was unconditional.
> > 
> > I'm attaching an example virtual/libudev which does the job. Sadly,
> > because of the 'extras' compatibility it's a big ugly conditional.
> 
> I'm going to ask here, because of the discussion on IRC, that you not
> commit this yet. There are issues still we need to work out wrt
> packaging systemd and udev.

So, can I commit the virtual and finally start fixing people's systems
or are we going to discuss this to the day when other options are no
longer a possibility and virtual will be necessary?

You seem still not to understand that upstream *does not care*.
And either way, merging udev and systemd will result that two, four or
six months from now users will need to manually re-adjust their @world
to have the packages split again.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: virtual/libudev

[Thomas Sachau]

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

Michał Górny schrieb:
> On Tue, 10 Jul 2012 14:24:27 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
>> On Tue, Jul 10, 2012 at 05:18:00PM +0200, Michał Górny wrote:
>>> Hello, all.
>>>
>>> Since nowadays udev is bundled within systemd, we start having two
>>> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
>>> the long story short, I would like to introduce a virtual for
>>> libudev which would pull in either of those two.
>>>
>>> There are three USE flags used in conditionals when depending on
>>> udev:
>>> - gudev - for glib wrapper on udev,
>>> - hwdb - to pull in hwids,
>>> - static-libs.
>>>
>>> The former two were previously provided by 'extras' USE flag,
>>> and the third was unconditional.
>>>
>>> I'm attaching an example virtual/libudev which does the job. Sadly,
>>> because of the 'extras' compatibility it's a big ugly conditional.
>>
>> I'm going to ask here, because of the discussion on IRC, that you not
>> commit this yet. There are issues still we need to work out wrt
>> packaging systemd and udev.
> 
> So, can I commit the virtual and finally start fixing people's systems
> or are we going to discuss this to the day when other options are no
> longer a possibility and virtual will be necessary?
> 
> You seem still not to understand that upstream *does not care*.
> And either way, merging udev and systemd will result that two, four or
> six months from now users will need to manually re-adjust their @world
> to have the packages split again.
> 

I wrote it the last time you asked and i write it this time again: NO!

Beside that, the last time i wrote you a mail about this topic, where
you did not respond at all. So please read it again and answer it. Such
change should be properly checked, before we even think about the idea
of such a switch.

-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-dev] RFC: virtual/libudev

[Michał Górny]

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

On Fri, 10 Aug 2012 19:33:10 +0200
Thomas Sachau <tommy@gentoo.org> wrote:

> Michał Górny schrieb:
> > On Tue, 10 Jul 2012 14:24:27 -0500
> > William Hubbs <williamh@gentoo.org> wrote:
> > 
> >> On Tue, Jul 10, 2012 at 05:18:00PM +0200, Michał Górny wrote:
> >>> Hello, all.
> >>>
> >>> Since nowadays udev is bundled within systemd, we start having two
> >>> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
> >>> the long story short, I would like to introduce a virtual for
> >>> libudev which would pull in either of those two.
> >>>
> >>> There are three USE flags used in conditionals when depending on
> >>> udev:
> >>> - gudev - for glib wrapper on udev,
> >>> - hwdb - to pull in hwids,
> >>> - static-libs.
> >>>
> >>> The former two were previously provided by 'extras' USE flag,
> >>> and the third was unconditional.
> >>>
> >>> I'm attaching an example virtual/libudev which does the job.
> >>> Sadly, because of the 'extras' compatibility it's a big ugly
> >>> conditional.
> >>
> >> I'm going to ask here, because of the discussion on IRC, that you
> >> not commit this yet. There are issues still we need to work out wrt
> >> packaging systemd and udev.
> > 
> > So, can I commit the virtual and finally start fixing people's
> > systems or are we going to discuss this to the day when other
> > options are no longer a possibility and virtual will be necessary?
> > 
> > You seem still not to understand that upstream *does not care*.
> > And either way, merging udev and systemd will result that two, four
> > or six months from now users will need to manually re-adjust their
> > @world to have the packages split again.
> > 
> 
> I wrote it the last time you asked and i write it this time again: NO!
> 
> Beside that, the last time i wrote you a mail about this topic, where
> you did not respond at all. So please read it again and answer it.
> Such change should be properly checked, before we even think about
> the idea of such a switch.

I'm pretty sure I replied to every mail I got from you.

And please remind me: what is your relevance to systemd or udev? What
do you know about history of those packages?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: virtual/libudev

[Thomas Sachau]

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

Michał Górny schrieb:
> On Fri, 10 Aug 2012 19:33:10 +0200
> Thomas Sachau <tommy@gentoo.org> wrote:
> 
>> Michał Górny schrieb:
>>> On Tue, 10 Jul 2012 14:24:27 -0500
>>> William Hubbs <williamh@gentoo.org> wrote:
>>>
>>>> On Tue, Jul 10, 2012 at 05:18:00PM +0200, Michał Górny wrote:
>>>>> Hello, all.
>>>>>
>>>>> Since nowadays udev is bundled within systemd, we start having two
>>>>> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
>>>>> the long story short, I would like to introduce a virtual for
>>>>> libudev which would pull in either of those two.
>>>>>
>>>>> There are three USE flags used in conditionals when depending on
>>>>> udev:
>>>>> - gudev - for glib wrapper on udev,
>>>>> - hwdb - to pull in hwids,
>>>>> - static-libs.
>>>>>
>>>>> The former two were previously provided by 'extras' USE flag,
>>>>> and the third was unconditional.
>>>>>
>>>>> I'm attaching an example virtual/libudev which does the job.
>>>>> Sadly, because of the 'extras' compatibility it's a big ugly
>>>>> conditional.
>>>>
>>>> I'm going to ask here, because of the discussion on IRC, that you
>>>> not commit this yet. There are issues still we need to work out wrt
>>>> packaging systemd and udev.
>>>
>>> So, can I commit the virtual and finally start fixing people's
>>> systems or are we going to discuss this to the day when other
>>> options are no longer a possibility and virtual will be necessary?
>>>
>>> You seem still not to understand that upstream *does not care*.
>>> And either way, merging udev and systemd will result that two, four
>>> or six months from now users will need to manually re-adjust their
>>> @world to have the packages split again.
>>>
>>
>> I wrote it the last time you asked and i write it this time again: NO!
>>
>> Beside that, the last time i wrote you a mail about this topic, where
>> you did not respond at all. So please read it again and answer it.
>> Such change should be properly checked, before we even think about
>> the idea of such a switch.
> 
> I'm pretty sure I replied to every mail I got from you.
> 
> And please remind me: what is your relevance to systemd or udev? What
> do you know about history of those packages?
> 

Please keep this on a technical level, neither relevance nor knowledge
about history should matter here.

Since you seem to have missed or forgotten my mails, let me copy it here
again for you:

>> As discussed on IRC, there is still no consensus for installing the
>> udev files with systemd, which is the beginning for the block and the
>> virtual. So we should first sort that point out, before we even start
>> to think about an ebuild for an udev virtual.
> 
> Do you have a technical or policy reason prohibiting me from maintaining
> a systemd ebuild following the upstream policies?

How about this simple one: The udev ebuild does already install udev, so
why should we have another package also installing the same thing,
resulting in a blocker, the need to switch from one package to another
and the need for package maintainers to switch their dependencies?

Since William already said, that he will move the udev installation to
/usr/lib, i dont see any technical reason left to not simply depend on
the udev ebuild.
And if you fear issues about not knowing which parts to install, then
just check the files installed by the udev ebuild, remove them from your
systemd ebuild and you are done.
> 
>> So for now: A clear no, i am against adding a virtual/libudev ebuild.
> 
> Please give the rationale.

I did above. So if you still want to install udev yourself, please give
the rationale for doing so. And neither upstream naming nor a big
upstream tarball nor the Makefile do force this, so please exclude those
points.





-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-dev] RFC: virtual/libudev

[Peter Alfredsen]

This outcome was just super. Systemd was bumped to -188 today. Udev is
still at -187. Instead of actually listening to upstream[1], which
would be easy with a virtual, we're now stuck with one part of the duo
being at one version and the other part of the duo another. And when I
login to X with this combo, my display is /upside-down/. And I don't
know if it's because our hackery on the tarball has left out some
vital part, because disabling stuff in the one ebuild (gudev in
systemd) and enabling it in the other is going to cause some
non-trivial problem, or if it's simply a bug upstream. But that's
okay, because gentooers are powerusers and we're supposed to have the
time to debug this stuff, right?
This is disgusting. Really. Virtuals are simple. This stuff is
freaking *hard*. Whoever it was that forced this on systemd in gentoo
should have a big *object* stuck in *place* and be forced to *action*
as penance for the time I'll have to waste fixing this.

[1]  "And what we will certainly not do is compromise the uniform integration
into systemd for some cosmetic improvements for non-systemd systems.

(Yes, udev on non-systemd systems is in our eyes a dead end, in case you
haven't noticed it yet. I am looking forward to the day when we can drop
that support entirely.)"
http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html

Meaning: For now, you're allowed to have udev without systemd but
mixing-and-matching udev versions and systemd versions will be
unsupported and patching udev will probably break systemd at some
point.

TL;DR: This is a sucky situation you've put all users of udev in.

Re: [gentoo-dev] RFC: virtual/libudev

[Michał Górny]

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

On Sat, 11 Aug 2012 20:11:18 +0200
Peter Alfredsen <peter.alfredsen@gmail.com> wrote:

> This outcome was just super. Systemd was bumped to -188 today. Udev is
> still at -187. Instead of actually listening to upstream[1], which
> would be easy with a virtual, we're now stuck with one part of the duo
> being at one version and the other part of the duo another. And when I
> login to X with this combo, my display is /upside-down/.

What was your previous state? Were you using older systemd with newer
udev?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: virtual/libudev

[Peter Alfredsen]

On Sat, Aug 11, 2012 at 8:29 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Sat, 11 Aug 2012 20:11:18 +0200
> Peter Alfredsen <peter.alfredsen@gmail.com> wrote:
>
>> This outcome was just super. Systemd was bumped to -188 today. Udev is
>> still at -187. Instead of actually listening to upstream[1], which
>> would be easy with a virtual, we're now stuck with one part of the duo
>> being at one version and the other part of the duo another. And when I
>> login to X with this combo, my display is /upside-down/.
>
> What was your previous state? Were you using older systemd with newer
> udev?

No, I was using the integrated package -187. Downgrading fixed the problem.

/Peter

Re: [gentoo-dev] RFC: virtual/libudev

[Samuli Suominen]

On 07/10/2012 06:18 PM, Michał Górny wrote:
> An alternative would be to provide separate virtual/libudev
> and virtual/libgudev; and maybe changing ebuilds not to depend on
> [hwids] but rather pull in sys-apps/hwids directly (since that's what
> the flag does).

USE=hwdb should be reviewed:

<udev-180 used to have ./configure switch for --enable/--disable-hwdb
 >udev-180 was bumped without taking care of the switch, and the ebuild 
got QA warning
then it was fixed for something else, and the `use_enable` was dropped 
to supress the warning
and then hwids was made into a separate package

so knowing all that, I would simply kill USE=hwdb and always pull in the 
package, as it used to be for avoiding pulling in the actual 
pciutils/usbutils with their dependencies, but is not worth for the 
separate hwids package anymore

>
> What are you thoughts?
>

Re: [gentoo-dev] RFC: virtual/libudev

[Diego Elio Pettenò]

Il 11/07/2012 10:03, Samuli Suominen ha scritto:
> 
> 
> so knowing all that, I would simply kill USE=hwdb and always pull in the
> package, as it used to be for avoiding pulling in the actual
> pciutils/usbutils with their dependencies, but is not worth for the
> separate hwids package anymore

Sounds good to me — the hwids package itself should be easy to deal
with, and it solves the whole issue of depending on the "big" packages.
Although I also have a replacement of mine (mini-hwdata) when the hwids
themselves are overkill.

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

Re: [gentoo-dev] RFC: virtual/libudev

[Samuli Suominen]

On 07/10/2012 06:18 PM, Michał Górny wrote:
> Hello, all.
>
> Since nowadays udev is bundled within systemd, we start having two
> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
> the long story short, I would like to introduce a virtual for libudev
> which would pull in either of those two.

sys-apps/systemd with USE="systemd" where USE="-systemd" would only 
install udev

and a virtual/udev for handling the migration period:

|| ( sys-apps/systemd <sys-fs/udev-186 )

the way it's currently in tree is not the way to go, and is somewhat 
obstructing the systemd maintaince.  as in, I can see where you are 
coming with this thread.

Re: [gentoo-dev] RFC: virtual/libudev

[Michał Górny]

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

On Wed, 11 Jul 2012 11:31:03 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 07/10/2012 06:18 PM, Michał Górny wrote:
> > Hello, all.
> >
> > Since nowadays udev is bundled within systemd, we start having two
> > libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
> > the long story short, I would like to introduce a virtual for
> > libudev which would pull in either of those two.
> 
> sys-apps/systemd with USE="systemd" where USE="-systemd" would only 
> install udev
> 
> and a virtual/udev for handling the migration period:
> 
> || ( sys-apps/systemd <sys-fs/udev-186 )
> 
> the way it's currently in tree is not the way to go, and is somewhat 
> obstructing the systemd maintaince.  as in, I can see where you are 
> coming with this thread.

I don't understand how it obstructs systemd maintenance.

-- 
Best regards,
Michał Górny

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