Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

RFC: virtual/libudev

 

 

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


mgorny at gentoo

Jul 10, 2012, 8:18 AM

Post #1 of 47 (623 views)
Permalink
RFC: virtual/libudev

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
Attachments: libudev-0.ebuild (0.92 KB)
  signature.asc (0.31 KB)


aballier at gentoo

Jul 10, 2012, 9:54 AM

Post #2 of 47 (611 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

On Tue, 10 Jul 2012 17:18:00 +0200
Michał Górny <mgorny [at] gentoo> 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.


mgorny at gentoo

Jul 10, 2012, 10:57 AM

Post #3 of 47 (611 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

On Tue, 10 Jul 2012 12:54:31 -0400
Alexis Ballier <aballier [at] gentoo> wrote:

> On Tue, 10 Jul 2012 17:18:00 +0200
> Michał Górny <mgorny [at] gentoo> 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
Attachments: signature.asc (0.31 KB)


williamh at gentoo

Jul 10, 2012, 11:15 AM

Post #4 of 47 (608 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

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 [at] gentoo> wrote:
>
> > On Tue, 10 Jul 2012 17:18:00 +0200
> > Michał Górny <mgorny [at] gentoo> 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


tommy at gentoo

Jul 10, 2012, 12:23 PM

Post #5 of 47 (609 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

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
Attachments: signature.asc (0.37 KB)


williamh at gentoo

Jul 10, 2012, 12:24 PM

Post #6 of 47 (607 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

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


yngwin at gentoo

Jul 10, 2012, 9:51 PM

Post #7 of 47 (606 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

On 11 July 2012 03:23, Thomas Sachau <tommy [at] gentoo> 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


1i5t5.duncan at cox

Jul 10, 2012, 11:34 PM

Post #8 of 47 (610 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

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


mgorny at gentoo

Jul 11, 2012, 12:15 AM

Post #9 of 47 (612 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

On Wed, 11 Jul 2012 12:51:50 +0800
Ben de Groot <yngwin [at] gentoo> wrote:

> On 11 July 2012 03:23, Thomas Sachau <tommy [at] gentoo> 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
Attachments: signature.asc (0.31 KB)


ssuominen at gentoo

Jul 11, 2012, 1:03 AM

Post #10 of 47 (607 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

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


1i5t5.duncan at cox

Jul 11, 2012, 1:27 AM

Post #11 of 47 (605 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

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 [at] gentoo>
> 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


ssuominen at gentoo

Jul 11, 2012, 1:31 AM

Post #12 of 47 (606 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

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.


mgorny at gentoo

Jul 11, 2012, 1:33 AM

Post #13 of 47 (605 views)
Permalink
Re: Re: RFC: virtual/libudev [In reply to]

On Wed, 11 Jul 2012 08:27:48 +0000 (UTC)
Duncan <1i5t5.duncan [at] cox> 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 [at] gentoo>
> > 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
Attachments: signature.asc (0.31 KB)


flameeyes at flameeyes

Jul 11, 2012, 1:56 AM

Post #14 of 47 (607 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

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 [at] flameeyes — http://blog.flameeyes.eu/


rich0 at gentoo

Jul 11, 2012, 3:40 AM

Post #15 of 47 (601 views)
Permalink
Re: Re: RFC: virtual/libudev [In reply to]

On Wed, Jul 11, 2012 at 4:27 AM, Duncan <1i5t5.duncan [at] cox> 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


axs at gentoo

Jul 11, 2012, 6:02 AM

Post #16 of 47 (603 views)
Permalink
Re: Re: RFC: virtual/libudev [In reply to]

-----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 [at] cox>
> 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-----


mikemol at gmail

Jul 11, 2012, 6:49 AM

Post #17 of 47 (600 views)
Permalink
Re: Re: RFC: virtual/libudev [In reply to]

On Wed, Jul 11, 2012 at 9:02 AM, Ian Stakenvicius <axs [at] gentoo> 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 [at] cox>
>> 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


mgorny at gentoo

Jul 11, 2012, 7:04 AM

Post #18 of 47 (604 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

On Wed, 11 Jul 2012 11:31:03 +0300
Samuli Suominen <ssuominen [at] gentoo> 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
Attachments: signature.asc (0.31 KB)


rich0 at gentoo

Jul 11, 2012, 7:06 AM

Post #19 of 47 (608 views)
Permalink
Re: Re: RFC: virtual/libudev [In reply to]

On Wed, Jul 11, 2012 at 9:49 AM, Michael Mol <mikemol [at] gmail> 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


mgorny at gentoo

Jul 11, 2012, 7:09 AM

Post #20 of 47 (605 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

On Tue, 10 Jul 2012 21:23:39 +0200
Thomas Sachau <tommy [at] gentoo> 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
Attachments: signature.asc (0.31 KB)


mikemol at gmail

Jul 11, 2012, 7:26 AM

Post #21 of 47 (604 views)
Permalink
Re: Re: RFC: virtual/libudev [In reply to]

On Wed, Jul 11, 2012 at 10:06 AM, Rich Freeman <rich0 [at] gentoo> wrote:
> On Wed, Jul 11, 2012 at 9:49 AM, Michael Mol <mikemol [at] gmail> 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


rich0 at gentoo

Jul 11, 2012, 7:35 AM

Post #22 of 47 (604 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

On Wed, Jul 11, 2012 at 10:09 AM, Michał Górny <mgorny [at] gentoo> wrote:
> On Tue, 10 Jul 2012 21:23:39 +0200
> Thomas Sachau <tommy [at] gentoo> 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


mgorny at gentoo

Jul 11, 2012, 7:52 AM

Post #23 of 47 (602 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

On Wed, 11 Jul 2012 10:35:32 -0400
Rich Freeman <rich0 [at] gentoo> wrote:

> On Wed, Jul 11, 2012 at 10:09 AM, Michał Górny <mgorny [at] gentoo>
> wrote:
> > On Tue, 10 Jul 2012 21:23:39 +0200
> > Thomas Sachau <tommy [at] gentoo> 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
Attachments: signature.asc (0.31 KB)


rich0 at gentoo

Jul 11, 2012, 8:05 AM

Post #24 of 47 (610 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

On Wed, Jul 11, 2012 at 10:52 AM, Michał Górny <mgorny [at] gentoo> 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


tommy at gentoo

Jul 11, 2012, 11:26 AM

Post #25 of 47 (610 views)
Permalink
Re: RFC: virtual/libudev [In reply to]

Michał Górny schrieb:
> On Tue, 10 Jul 2012 21:23:39 +0200
> Thomas Sachau <tommy [at] gentoo> 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
Attachments: signature.asc (0.37 KB)

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.