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


floppym at gentoo

Jul 11, 2012, 12:27 PM

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

On Wed, Jul 11, 2012 at 2:26 PM, Thomas Sachau <tommy [at] gentoo> wrote:
> 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?

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.


williamh at gentoo

Jul 11, 2012, 12:54 PM

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

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


floppym at gentoo

Jul 11, 2012, 1:33 PM

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

On Wed, Jul 11, 2012 at 3:54 PM, William Hubbs <williamh [at] gentoo> 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.


williamh at gentoo

Jul 11, 2012, 1:54 PM

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

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


mgorny at gentoo

Jul 11, 2012, 2:04 PM

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

On Wed, 11 Jul 2012 15:27:41 -0400
Mike Gilbert <floppym [at] gentoo> 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
Attachments: signature.asc (0.31 KB)


waltdnes at waltdnes

Jul 11, 2012, 8:40 PM

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

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


vivo75 at gmail

Jul 12, 2012, 10:16 AM

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

Il 11/07/2012 22:33, Mike Gilbert ha scritto:
> On Wed, Jul 11, 2012 at 3:54 PM, William Hubbs<williamh [at] gentoo> 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.


peter.alfredsen at gmail

Jul 26, 2012, 2:44 PM

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

On Wed, Jul 11, 2012 at 11:04 PM, Michał Górny <mgorny [at] gentoo> wrote:
> On Wed, 11 Jul 2012 15:27:41 -0400
> Mike Gilbert <floppym [at] gentoo> 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


caneko at gmail

Jul 26, 2012, 3:08 PM

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

On Thu, Jul 26, 2012 at 4:44 PM, Peter Alfredsen
<peter.alfredsen [at] gmail> wrote:
> On Wed, Jul 11, 2012 at 11:04 PM, Michał Górny <mgorny [at] gentoo> wrote:
>> On Wed, 11 Jul 2012 15:27:41 -0400
>> Mike Gilbert <floppym [at] gentoo> 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


1i5t5.duncan at cox

Jul 26, 2012, 7:37 PM

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

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


caneko at gmail

Jul 26, 2012, 7:49 PM

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

On Thu, Jul 26, 2012 at 9:37 PM, Duncan <1i5t5.duncan [at] cox> 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


williamh at gentoo

Jul 27, 2012, 8:50 AM

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

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


neddyseagoon at gentoo

Jul 28, 2012, 9:51 AM

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

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)


1i5t5.duncan at cox

Jul 28, 2012, 5:14 PM

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

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


peter at stuge

Jul 28, 2012, 6:01 PM

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

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


mgorny at gentoo

Aug 10, 2012, 12:59 AM

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

On Tue, 10 Jul 2012 14:24:27 -0500
William Hubbs <williamh [at] gentoo> 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
Attachments: signature.asc (0.31 KB)


tommy at gentoo

Aug 10, 2012, 10:33 AM

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

Michał Górny schrieb:
> On Tue, 10 Jul 2012 14:24:27 -0500
> William Hubbs <williamh [at] gentoo> 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
Attachments: signature.asc (0.37 KB)


mgorny at gentoo

Aug 10, 2012, 11:13 AM

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

On Fri, 10 Aug 2012 19:33:10 +0200
Thomas Sachau <tommy [at] gentoo> wrote:

> Michał Górny schrieb:
> > On Tue, 10 Jul 2012 14:24:27 -0500
> > William Hubbs <williamh [at] gentoo> 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
Attachments: signature.asc (0.31 KB)


tommy at gentoo

Aug 10, 2012, 1:23 PM

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

Michał Górny schrieb:
> On Fri, 10 Aug 2012 19:33:10 +0200
> Thomas Sachau <tommy [at] gentoo> wrote:
>
>> Michał Górny schrieb:
>>> On Tue, 10 Jul 2012 14:24:27 -0500
>>> William Hubbs <williamh [at] gentoo> 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
Attachments: signature.asc (0.37 KB)


peter.alfredsen at gmail

Aug 11, 2012, 11:11 AM

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

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.


mgorny at gentoo

Aug 11, 2012, 11:29 AM

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

On Sat, 11 Aug 2012 20:11:18 +0200
Peter Alfredsen <peter.alfredsen [at] gmail> 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
Attachments: signature.asc (0.31 KB)


peter.alfredsen at gmail

Aug 11, 2012, 11:39 AM

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

On Sat, Aug 11, 2012 at 8:29 PM, Michał Górny <mgorny [at] gentoo> wrote:
> On Sat, 11 Aug 2012 20:11:18 +0200
> Peter Alfredsen <peter.alfredsen [at] gmail> 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

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.