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-10-2012, 04:54 PM
Alexis Ballier
 
Default RFC: virtual/libudev

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.
 
Old 07-10-2012, 05:57 PM
Michał Górny
 
Default RFC: virtual/libudev

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
 
Old 07-10-2012, 06:15 PM
William Hubbs
 
Default RFC: virtual/libudev

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

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

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
 
Old 07-11-2012, 04:51 AM
Ben de Groot
 
Default RFC: virtual/libudev

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
 
Old 07-11-2012, 06:34 AM
Duncan
 
Default RFC: virtual/libudev

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

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
 
Old 07-11-2012, 08:03 AM
Samuli Suominen
 
Default RFC: virtual/libudev

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?
 
Old 07-11-2012, 08:27 AM
Duncan
 
Default RFC: virtual/libudev

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
 

Thread Tools




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

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