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, 08:31 AM
Samuli Suominen
 
Default RFC: virtual/libudev

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.
 
Old 07-11-2012, 08:33 AM
Michał Górny
 
Default RFC: virtual/libudev

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
 
Old 07-11-2012, 08:56 AM
Diego Elio Pettenò
 
Default RFC: virtual/libudev

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/
 
Old 07-11-2012, 10:40 AM
Rich Freeman
 
Default RFC: virtual/libudev

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
 
Old 07-11-2012, 01:02 PM
Ian Stakenvicius
 
Default RFC: virtual/libudev

-----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-----
 
Old 07-11-2012, 01:49 PM
Michael Mol
 
Default RFC: virtual/libudev

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

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

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

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
 
Old 07-11-2012, 02:26 PM
Michael Mol
 
Default RFC: virtual/libudev

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
 

Thread Tools




All times are GMT. The time now is 09:34 AM.

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