Moving from old udev to eudev

classic Classic list List threaded Threaded
108 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Anthony G. Basile-2
On 08/05/2013 06:19 AM, Samuli Suominen wrote:

> On 04/08/13 05:56, Walter Dnes wrote:
>> On Fri, Aug 02, 2013 at 05:02:39AM +0300, Samuli Suominen wrote
>>
>>> Looking forward to lastrite sys-fs/eudev just like
>>> sys-apps/module-init-tools already was removed as unnecessary later on.
>>
>>    You want eudev removed, and Lennart Poettering wants udev on
>> non-systemd systems dropped.  Add those two items together, and we get
>> systemd rammed down our throats...
>>
>> http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
>>
>>
>>> (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.)
>>
>
> That might be the systemd upstream view point, but definately isn't mine.
> Fact is that udev can be built and ran standalone without systemd and
> you don't need eudev for that.

For now.  And you get a ton of bloat.  I removed over 300 unused
functions.  Furthermore, there is a problem with iface renaming which
Ian solved and legacy features are not there.  We will continue to
support a bootable system with separate /usr without need for an intramfs.

But most importantly, you have a different upstream with a different
attitude towards the users.  Even if the codebase were identical, this
makes all the difference to those who want a system the way they want
and not the way systemd upstream wants.  Your arguments have been
ineffective at convincing people because you dismiss this critical point.


> If udev upstream makes it impossible to build, or run it standalone then
> we need to patch or fork it -- but that's far from now.
> In any case there will always be sys-fs/udev and it will never require
> sys-apps/systemd.
> Futhermore sys-fs/udev will be the default for long as sys-apps/openrc
> is the default.
>
> I mean, why the heck fork something too early when upstream still
> supports udev on non-systemd init systems?!
>
> - Samuli


--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

tanstaafl-2
On 2013-08-05 10:10 AM, Anthony G. Basile <[hidden email]> wrote:
> On 08/05/2013 06:19 AM, Samuli Suominen wrote:
>> That might be the systemd upstream view point, but definately isn't mine.
>> Fact is that udev can be built and ran standalone without systemd and
>> you don't need eudev for that.

> For now.

And this is ultimately my primary concern. After reading the huge
threads surrounding this debacle, I wouldn't trust Lennart (or the other
systemd devs) on any promise to not remove this ability at a later date.

> And you get a ton of bloat.

And this is the second concern. Both of these are why I decided to go
with eudev. I looked at mdev, but it looked a lot more complicated to
get right than eudev (correct me if I'm wrong someone).

Thanks again Anthony for your work maintaining eudev for 'the rest of
us'... :)

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

tanstaafl-2
In reply to this post by Neil Bothwick
Going back and re-reading finds this answer to my other last question -
also from you Neil (so thanks again!)...

But I'm curious...

On 2013-08-01 2:43 PM, Neil Bothwick <[hidden email]> wrote:

> On Thu, 01 Aug 2013 12:28:38 -0400, Tanstaafl wrote:
>
>> >I've googled until my fingers are blue, but cannot for the life of me
>> >find any explicit instructions for*how*  to switch from udev to eudev.
> emerge -Ca udev
> emerge -1a eudev
>
> But there's not a lot of point as eudev isn't that different to udev now,
> AFAICT, and a recent update forced me to switch back to udev because
> eudev hadn't been updated (on ~amd64).

Can you elaborate on what this update was that forced you to go back to
regular udev? This is the only 'concern' that I have right now, and
this is the first comment I've seen from anyone about anything like this...

Thanks again,

Charles

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Neil Bothwick
On Mon, 05 Aug 2013 10:24:27 -0400, Tanstaafl wrote:

> > But there's not a lot of point as eudev isn't that different to udev
> > now, AFAICT, and a recent update forced me to switch back to udev
> > because eudev hadn't been updated (on ~amd64).  
>
> Can you elaborate on what this update was that forced you to go back to
> regular udev?

I can't remember what it was now, and it may have been avoidable by
making virtual/udev-206 (or whichever version it was that needed a higher
udev version than eudev could provide). It's moot now as eudev has been
updated and portage is happy again, but it would be a concern if this
happened regularly.


--
Neil Bothwick

PC DOS Error #01: Windows loading, come back tomorrow

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

tanstaafl-2
On 2013-08-05 4:18 PM, Neil Bothwick <[hidden email]> wrote:

> On Mon, 05 Aug 2013 10:24:27 -0400, Tanstaafl wrote:
>
>>> But there's not a lot of point as eudev isn't that different to udev
>>> now, AFAICT, and a recent update forced me to switch back to udev
>>> because eudev hadn't been updated (on ~amd64).
>>
>> Can you elaborate on what this update was that forced you to go back to
>> regular udev?
>
> I can't remember what it was now, and it may have been avoidable by
> making virtual/udev-206 (or whichever version it was that needed a higher
> udev version than eudev could provide). It's moot now as eudev has been
> updated and portage is happy again, but it would be a concern if this
> happened regularly.

Agreed... Anthony, can you comment on the likelihood of this happening
in the future? An occasional temporary issue wouldn't trouble me, as I
already wait at least a few days before updating anything critical, and
it isn't like this kind of thing hasn't happened for regular udev...

Thanks for the reply Neil...

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Walter Dnes
In reply to this post by Samuli Suominen-4
On Mon, Aug 05, 2013 at 01:19:34PM +0300, Samuli Suominen wrote

> That might be the systemd upstream view point, but definately isn't mine.

  Your view and mine don't matter.  Upstream's view matters.  That's how
we end up with fiascos like GNOME and Microsoft's Metro interface.

> Fact is that udev can be built and ran standalone without systemd and
> you don't need eudev for that.

  Kay Sievers, *THE LEAD DEVELOPER* specifically says in
http://lists.freedesktop.org/archives/systemd-devel/2012-July/006065.html

> We promised to keep udev properly *running* as standalone, we never
> told that it can be *build* standalone. And that still stands

I.e. no promise of being able to build standalone.

> If udev upstream makes it impossible to build, or run it standalone
> then we need to patch or fork it -- but that's far from now.

[...deletia...]

> I mean, why the heck fork something too early when upstream still
> supports udev on non-systemd init systems?!

  Let's say that that it happens 2 years from now, after udev has been
getting ever more tightly integrated into systemd.  At that point, it'll
be way too late.  The udev source will have all sorts of hooks into
systemd, at least at build-time.  Creating a stand-alone build in a few
weeks would be painful.  Another option is to dig up 2-year-old source
code for the last stand-alone version of udev and update it in a rush.
The old version would depend on libs no-longer in the tree, and other
apps would depend on a newer udev.  You yourself, pointed out in
http://www.mail-archive.com/gentoo-user@.../msg139485.html

> By udev maintainers forcing them to upgrade to the new keymap hwdb
> which required version to be raised to up-to-par with udev-206.

  Imagine 2 years of such updates to catch up with in a few weeks.  It's
too late to start building the fire-escapes when the fire-alarm goes
off.  Similarly, if we want a viable alternative udev, that means having
it (eudev) maintained and up-to-date and ready at all times.  I'm sorry
that it has come to this, but the current udev maintainers have made it
clear which way they want to go, and it's not the way that I and a lot
of other people want to go.  Don't blame us for getting out while the
getting out is still good.

--
Walter Dnes <[hidden email]>
I don't run "desktop environments"; I run useful applications

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Walter Dnes
In reply to this post by Neil Bothwick
On Mon, Aug 05, 2013 at 09:18:38PM +0100, Neil Bothwick wrote

> On Mon, 05 Aug 2013 10:24:27 -0400, Tanstaafl wrote:
>
> > > But there's not a lot of point as eudev isn't that different to udev
> > > now, AFAICT, and a recent update forced me to switch back to udev
> > > because eudev hadn't been updated (on ~amd64).  
> >
> > Can you elaborate on what this update was that forced you to go back to
> > regular udev?
>
> I can't remember what it was now, and it may have been avoidable by
> making virtual/udev-206 (or whichever version it was that needed a higher
> udev version than eudev could provide). It's moot now as eudev has been
> updated and portage is happy again, but it would be a concern if this
> happened regularly.

  I ran into this.  Here is what I think happened...

- I specified "sys-fs/eudev-1.2-r1-beta ~amd64" (or something similar)
  in my /etc/portage/package.keywords file
- I ran "emerge --sync".  On that particular day, it removed the beta
  version ebuild, and replaced it with eudev-1.2.ebuild
- "emerge --changed-use --deep --update @world" could no longer find an
  unmasked version of sys-fs/eudev that satisfied virtual/udev.  So it
  fell back to a version of sys-fs/udev
- My workaround, *UNTIL SUCH TIME AS EUDEV HITS STABLE AMD64*, is...
<sys-fs/eudev-9999 ~amd64
  in my /etc/portage/package.keywords file.

  This specifies to accept the highest ebuild number that is smaller
than 9999 (the "bleeding edge" version).

--
Walter Dnes <[hidden email]>
I don't run "desktop environments"; I run useful applications

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Walter Dnes
In reply to this post by Anthony G. Basile-2
On Mon, Aug 05, 2013 at 10:10:45AM -0400, Anthony G. Basile wrote

> For now.  And you get a ton of bloat.  I removed over 300 unused
> functions.

  Wonderful.  It reminds me of...  http://www.quotationspage.com/quote/26979.html

> Perfection is achieved, not when there is nothing more to add,
> but when there is nothing left to take away.

> Antoine de Saint-Exupery
> French writer (1900 - 1944)

  That is a saying that should be taken to heart by more programmers,
both in the linux and Microsoft worlds.

--
Walter Dnes <[hidden email]>
I don't run "desktop environments"; I run useful applications

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Daniel Campbell-2
In reply to this post by Anthony G. Basile-2
On 08/05/2013 05:12 AM, Anthony G. Basile wrote:

> On 08/04/2013 11:56 AM, Dale wrote:
>> Anthony G. Basile wrote:
>>>
>>> I have refrained from flamewars, but I want to reassure people, eudev
>>> will not be dropped.
>>>
>>
>> I noticed the other day, posted on this thread by the way, that it left
>> beta too.  I'm assuming you are involved in the project so allow me to
>> say this:  THANKS MUCH!!!!!!
>>
>> Dale
>>
>> :-)  :-)
>>
>
> I am the current lead.  You may follow the activity here [1].
>
> [1] https://github.com/gentoo/eudev/commits/master
>
If I knew more about detecting hardware and knew more C, I'd gladly join
you in eudev development. As a user all I can offer is a hearty "thanks"
and a promise to report any bugs that I find. Your work is appreciated!

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Neil Bothwick
In reply to this post by Walter Dnes
On Mon, 5 Aug 2013 21:10:27 -0400, Walter Dnes wrote:

> > I can't remember what it was now, and it may have been avoidable by
> > making virtual/udev-206 (or whichever version it was that needed a
> > higher udev version than eudev could provide). It's moot now as eudev
> > has been updated and portage is happy again, but it would be a
> > concern if this happened regularly.  
>
>   I ran into this.  Here is what I think happened...
>
> - I specified "sys-fs/eudev-1.2-r1-beta ~amd64" (or something similar)
>   in my /etc/portage/package.keywords file
> - I ran "emerge --sync".  On that particular day, it removed the beta
>   version ebuild, and replaced it with eudev-1.2.ebuild
> - "emerge --changed-use --deep --update @world" could no longer find an
>   unmasked version of sys-fs/eudev that satisfied virtual/udev.  So it
>   fell back to a version of sys-fs/udev
> - My workaround, *UNTIL SUCH TIME AS EUDEV HITS STABLE AMD64*, is...
> <sys-fs/eudev-9999 ~amd64
>   in my /etc/portage/package.keywords file.
>
>   This specifies to accept the highest ebuild number that is smaller
> than 9999 (the "bleeding edge" version).
nothing that complicated, I have nothing in package.{un,}mask for eudev.
Something was pulling in virtual/udev-206, which no eudev releases at the
time could satisfy (except possibly the 9999 version but those are masked
by default) so portage needed to uinstall eudev and install udev to fulfil
the dependency.


--
Neil Bothwick

Sisko:"I won't be condescending to you this episode, Dr. Bashir."

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Anthony G. Basile-2
In reply to this post by Daniel Campbell-2
On 08/06/2013 07:20 AM, Daniel Campbell wrote:

> On 08/05/2013 05:12 AM, Anthony G. Basile wrote:
>> On 08/04/2013 11:56 AM, Dale wrote:
>>> Anthony G. Basile wrote:
>>>>
>>>> I have refrained from flamewars, but I want to reassure people, eudev
>>>> will not be dropped.
>>>>
>>>
>>> I noticed the other day, posted on this thread by the way, that it left
>>> beta too.  I'm assuming you are involved in the project so allow me to
>>> say this:  THANKS MUCH!!!!!!
>>>
>>> Dale
>>>
>>> :-)  :-)
>>>
>>
>> I am the current lead.  You may follow the activity here [1].
>>
>> [1] https://github.com/gentoo/eudev/commits/master
>>
> If I knew more about detecting hardware and knew more C, I'd gladly join
> you in eudev development. As a user all I can offer is a hearty "thanks"
> and a promise to report any bugs that I find. Your work is appreciated!
>

Please test and report any problems.  Isolate the problems as much as
possible (by commenting code or whatever) and this is 1/2 the battle.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

tanstaafl-2
In reply to this post by Neil Bothwick
On 2013-08-01 2:43 PM, Neil Bothwick <[hidden email]> wrote:
> On Thu, 01 Aug 2013 12:28:38 -0400, Tanstaafl wrote:
>
>> I've googled until my fingers are blue, but cannot for the life of me
>> find any explicit instructions for *how* to switch from udev to eudev.
>
> emerge -Ca udev
> emerge -1a eudev

Two last questions (first one never got answered, and I'm doing this in
the morning)...

Do I not have to

emerge -Ca virtual/udev

too?

Last - is simply restarting udev good enough, or should I go ahead and
reboot anyway before continuing with other updates?

Thanks again to all...

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Neil Bothwick
On Fri, 09 Aug 2013 07:12:50 -0400, Tanstaafl wrote:

> >> I've googled until my fingers are blue, but cannot for the life of me
> >> find any explicit instructions for *how* to switch from udev to
> >> eudev.  
> >
> > emerge -Ca udev
> > emerge -1a eudev  
>
> Two last questions (first one never got answered, and I'm doing this in
> the morning)...
>
> Do I not have to
>
> emerge -Ca virtual/udev
>
> too?
No, the virtual is always needed, eudev satisfies it. but you do need to
make sure your USE settings for eudev and virtual/udev match.


--
Neil Bothwick

CPU: (n.) acronym for Central Purging Unit. A device which discards or
distorts data sent to it, sometimes returning more data and sometimes
merely over-heating.

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

tanstaafl-2
On 2013-08-09 8:24 AM, Neil Bothwick <[hidden email]> wrote:

> On Fri, 09 Aug 2013 07:12:50 -0400, Tanstaafl wrote:
>
>>>> I've googled until my fingers are blue, but cannot for the life of me
>>>> find any explicit instructions for *how* to switch from udev to
>>>> eudev.
>>>
>>> emerge -Ca udev
>>> emerge -1a eudev
>>
>> Two last questions (first one never got answered, and I'm doing this in
>> the morning)...
>>
>> Do I not have to
>>
>> emerge -Ca virtual/udev
>>
>> too?
>
> No, the virtual is always needed, eudev satisfies it. but you do need to
> make sure your USE settings for eudev and virtual/udev match.

Ok... so, as long as I don't have anything for either of them in
package.use, I'm ok?

Or - *should* I have anything for them in package.use? The only thing I
have in there that I think is in any way related to udev (based on
memory about an issue with it that was related to udev when doing an
update a while back) is:

sys-apps/kmod tools

But nothing for either sys-fs/udev or virtual/udev...

Thanks Neil


Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Neil Bothwick
On Fri, 09 Aug 2013 08:45:47 -0400, Tanstaafl wrote:

> > No, the virtual is always needed, eudev satisfies it. but you do need
> > to make sure your USE settings for eudev and virtual/udev match.  
>
> Ok... so, as long as I don't have anything for either of them in
> package.use, I'm ok?
>
> Or - *should* I have anything for them in package.use? The only thing I
> have in there that I think is in any way related to udev (based on
> memory about an issue with it that was related to udev when doing an
> update a while back) is:
You should be OK, but portage will let you know if a needed flag is not
set. However, if you have a mismatch between the two packages, the virtual
may try to pull in udev instead. This happened to me once and it took a
while to work out that the issue was caused by USE flags.


--
Neil Bothwick

WinErr 008: Broken window - Watch out for glass fragments

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Samuli Suominen-4
In reply to this post by Neil Bothwick
On 05/08/13 23:18, Neil Bothwick wrote:

> On Mon, 05 Aug 2013 10:24:27 -0400, Tanstaafl wrote:
>
>>> But there's not a lot of point as eudev isn't that different to udev
>>> now, AFAICT, and a recent update forced me to switch back to udev
>>> because eudev hadn't been updated (on ~amd64).
>>
>> Can you elaborate on what this update was that forced you to go back to
>> regular udev?
>
> I can't remember what it was now, and it may have been avoidable by
> making virtual/udev-206 (or whichever version it was that needed a higher
> udev version than eudev could provide). It's moot now as eudev has been
> updated and portage is happy again, but it would be a concern if this
> happened regularly.

I expect it to happen around every new udev release that causes slight
incompability; the default of the virtual/udev, sys-fs/udev, doesn't
have to wait for the alternative providers.

- Samuli

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

tanstaafl-2
On 2013-08-10 2:57 AM, Samuli Suominen <[hidden email]> wrote:

> On 05/08/13 23:18, Neil Bothwick wrote:
>> On Mon, 05 Aug 2013 10:24:27 -0400, Tanstaafl wrote:
>>>> But there's not a lot of point as eudev isn't that different to udev
>>>> now, AFAICT, and a recent update forced me to switch back to udev
>>>> because eudev hadn't been updated (on ~amd64).
>>>
>>> Can you elaborate on what this update was that forced you to go back to
>>> regular udev?
>>
>> I can't remember what it was now, and it may have been avoidable by
>> making virtual/udev-206 (or whichever version it was that needed a higher
>> udev version than eudev could provide). It's moot now as eudev has been
>> updated and portage is happy again, but it would be a concern if this
>> happened regularly.
>
> I expect it to happen around every new udev release that causes slight
> incompability; the default of the virtual/udev, sys-fs/udev, doesn't
> have to wait for the alternative providers.

And thanks for the heads up Samuli.

I always emerge -pvuDN world and look very carefully at the results, and
I also wait at least 2 or 3 days before installing any system critical
updates (has saved me headaches more than once).

Ok, here goes... ;)

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev - Reboot Necessary?

tanstaafl-2
In reply to this post by tanstaafl-2
On 2013-08-09 7:12 AM, Tanstaafl <[hidden email]> wrote:
> Last - is simply restarting udev good enough, or should I go ahead and
> reboot anyway before continuing with other updates?

Never got a response to this...

I'd prefer to not reboot if I don't have to, but it isn't *that* big a
deal if it is 'recommended'...

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev - Reboot Necessary?

tanstaafl-2
On 2013-08-10 10:25 AM, Tanstaafl <[hidden email]> wrote:
> On 2013-08-09 7:12 AM, Tanstaafl <[hidden email]> wrote:
>> Last - is simply restarting udev good enough, or should I go ahead and
>> reboot anyway before continuing with other updates?
>
> Never got a response to this...
>
> I'd prefer to not reboot if I don't have to, but it isn't *that* big a
> deal if it is 'recommended'...

Two other related questions...

1. Would it be correct to say that if you don't get an error when
restarting udev, you *shouldn't* (I know there are never any guarantees)
get an error when rebooting?

and

2. What happens if I

/etc/init.d/udev restart

and there is an error of some kind?

Will it cause my mail server to come crashing down? Or will it keep
running until I can determine the error and fix it?

Keep in mind - this is a server, and just runs
postfix/dovecot/apache/mysql...

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

tanstaafl-2
In reply to this post by tanstaafl-2
Hmmm...

Do I need (I don't think so) the kmod USE flag set for eudev and
virtual/udev?

I have kernel modules disabled on this system.

123456