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

» Linux Archive

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


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-11-2012, 02:35 PM
Rich Freeman
 
Default RFC: virtual/libudev

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
 
Old 07-11-2012, 02:52 PM
Michał Górny
 
Default RFC: virtual/libudev

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
 
Old 07-11-2012, 03:05 PM
Rich Freeman
 
Default RFC: virtual/libudev

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
 
Old 07-11-2012, 06:26 PM
Thomas Sachau
 
Default RFC: virtual/libudev

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
 
Old 07-11-2012, 07:27 PM
Mike Gilbert
 
Default RFC: virtual/libudev

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.
 
Old 07-11-2012, 07:54 PM
William Hubbs
 
Default RFC: virtual/libudev

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
 
Old 07-11-2012, 08:33 PM
Mike Gilbert
 
Default RFC: virtual/libudev

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.
 
Old 07-11-2012, 08:54 PM
William Hubbs
 
Default RFC: virtual/libudev

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
 
Old 07-11-2012, 09:04 PM
Michał Górny
 
Default RFC: virtual/libudev

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
 
Old 07-12-2012, 03:40 AM
"Walter Dnes"
 
Default RFC: virtual/libudev

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>
 

Thread Tools




All times are GMT. The time now is 07:54 AM.

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