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

Neil Bothwick
On Sat, 10 Aug 2013 10:33:48 -0400, Tanstaafl 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?  

Restarting worked for me on a server. On my laptop I switched over at the
same tome as a kernel update, so I had to reboot anyway.

> > 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?
That sounds reasonable. I find checkrestart to be useful in these
situations. If it reports everything OK, you will be fine.

> and
>
> 2. What happens if I
>
> /etc/init.d/udev restart
>
> and there is an error of some kind?

Find someone to blame, but not me ;-)
 
> 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...

I don't see it being a problem, but in that case, a reboot should clear
things. Just make sure you have a package of udev available in case
things do go TU.


--
Neil Bothwick

COMMAND: A suggestion made to a computer.

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

SOLVED: Re: [gentoo-user] Moving from old udev to eudev

tanstaafl-2
In reply to this post by tanstaafl-2
On 2013-08-10 8:11 AM, Tanstaafl <[hidden email]> wrote:
> 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... ;)

Well, that was about as uneventful as it gets.

emerge -C udev

emerge -1 eudev

etc-update, accepted changes

/etc/init.d/udev restart

Done...

Thanks very much to all who replied to ease my worried mind (especially
Neil). :)

I added a forum thread about this, just for closure:

http://forums.gentoo.org/viewtopic-p-7369696.html#7369696

Reply | Threaded
Open this post in threaded view
|

Re: SOLVED: Re: [gentoo-user] Moving from old udev to eudev

Dale-46
Tanstaafl wrote:

> On 2013-08-10 8:11 AM, Tanstaafl <[hidden email]> wrote:
>> 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... ;)
>
> Well, that was about as uneventful as it gets.
>
> emerge -C udev
>
> emerge -1 eudev
>
> etc-update, accepted changes
>
> /etc/init.d/udev restart
>
> Done...
>
> Thanks very much to all who replied to ease my worried mind
> (especially Neil). :)
>
> I added a forum thread about this, just for closure:
>
> http://forums.gentoo.org/viewtopic-p-7369696.html#7369696
>
>

Glad it went well.  If you hadn't asked, it could have been a disaster.
Murphy's law you know.  ;-)

Dale

:-)  :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!


Reply | Threaded
Open this post in threaded view
|

Re: SOLVED: Re: [gentoo-user] Moving from old udev to eudev

tanstaafl-2
On 2013-08-10 2:47 PM, Dale <[hidden email]> wrote:

> Tanstaafl wrote:
>> Well, that was about as uneventful as it gets.
>>
>> emerge -C udev
>>
>> emerge -1 eudev
>>
>> etc-update, accepted changes
>>
>> /etc/init.d/udev restart
>>
>> Done...
>>
>> Thanks very much to all who replied to ease my worried mind
>> (especially Neil). :)
>>
>> I added a forum thread about this, just for closure:
>>
>> http://forums.gentoo.org/viewtopic-p-7369696.html#7369696

> Glad it went well.  If you hadn't asked, it could have been a disaster.
> Murphy's law you know.  ;-)

Exactly... ;)

Also, to correct the above - I did do one other thing, but didn't see it
until I went to emerge something else...

When I emerged another app after updating udev, after the successful
emerge there was a warning about some preserved libs fro the old udev,
and it told me to (and so I did):

emerge @preserved-rebuild

to rebuild lvm2...

Thanks again... :) I'm just about done updating everything else that had
gotten backed up by my holding off on doing anything about udev...

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 Sat, Aug 10, 2013 at 09:57:52AM +0300, Samuli Suominen wrote

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

  The elegant solution is outlined in my post...
http://www.gossamer-threads.com/lists/gentoo/user/275977#275977

I.e. *UNTIL SUCH TIME AS EUDEV HITS STABLE* (on whatever arch you're
using), add the entry

<sys-fs/eudev-9999 ~amd64

to package.keywords (replace amd64 with your arch if necessary).
Basically, if you keyword a specific version, and the ebuild gets
removed by "emerge --sync", there are no eudev ebuilds to satisfy
virtual/udev.  So portage falls back to udev.  My solution isn't
hard-coded to any one version, and is immune to to version bumps and
removals.

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

Samuli Suominen-4
On 11/08/13 08:36, Walter Dnes wrote:

> On Sat, Aug 10, 2013 at 09:57:52AM +0300, Samuli Suominen wrote
>
>> 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.
>
>    The elegant solution is outlined in my post...
> http://www.gossamer-threads.com/lists/gentoo/user/275977#275977
>
> I.e. *UNTIL SUCH TIME AS EUDEV HITS STABLE* (on whatever arch you're
> using), add the entry
>
> <sys-fs/eudev-9999 ~amd64
>
> to package.keywords (replace amd64 with your arch if necessary).
> Basically, if you keyword a specific version, and the ebuild gets
> removed by "emerge --sync", there are no eudev ebuilds to satisfy
> virtual/udev.  So portage falls back to udev.  My solution isn't
> hard-coded to any one version, and is immune to to version bumps and
> removals.
>

bad idea to unmask "the new multilib eudev" on stable, regarding
blockers it has like
"!<=app-emulation/emul-linux-x86-baselibs-20130224-r7" on amd64 multilib
when ABI_X86="32" is enabled

as in, unresolvable dependencies

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 Sun, 11 Aug 2013 01:36:59 -0400, Walter Dnes wrote:

> > 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.  
>
>   The elegant solution is outlined in my post...
> http://www.gossamer-threads.com/lists/gentoo/user/275977#275977
>
> I.e. *UNTIL SUCH TIME AS EUDEV HITS STABLE* (on whatever arch you're
> using), add the entry
>
> <sys-fs/eudev-9999 ~amd64
I'm afraid that doesn't solve the problem I had at all, because I'm
running ~arch. It's as Samuli said, the eudev release lagged behind udev,
causing the virtual to look elsewhere for its satisfaction.


--
Neil Bothwick

Loose bits sink chips.

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-11 6:04 AM, Neil Bothwick <[hidden email]> wrote:
> I'm afraid that doesn't solve the problem I had at all, because I'm
> running ~arch. It's as Samuli said, the eudev release lagged behind udev,
> causing the virtual to look elsewhere for its satisfaction.

So, looks like the best strategy is not to blindly update eudev, and
always check these things, before attempting an upgrade, and waiting for
it to catch up if/when it happens.

No biggie, except maybe for those used to just blindly updating
everything without looking.

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Neil Bothwick
On Sun, 11 Aug 2013 10:25:33 -0400, Tanstaafl wrote:

> On 2013-08-11 6:04 AM, Neil Bothwick <[hidden email]> wrote:
> > I'm afraid that doesn't solve the problem I had at all, because I'm
> > running ~arch. It's as Samuli said, the eudev release lagged behind
> > udev, causing the virtual to look elsewhere for its satisfaction.  
>
> So, looks like the best strategy is not to blindly update eudev, and
> always check these things, before attempting an upgrade, and waiting
> for it to catch up if/when it happens.

Well, you shouldn't blindly update anything, but the issue here was
eudev *not* being updated when the virtual was, and both cause and
result were quite clear.
 
> No biggie, except maybe for those used to just blindly updating
> everything without looking.

Those people are used to dealing with breakage, or soon will be :)


--
Neil Bothwick

Save the whales. Collect the whole set.

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-11 11:15 AM, Neil Bothwick <[hidden email]> wrote:
> On Sun, 11 Aug 2013 10:25:33 -0400, Tanstaafl wrote:
>> So, looks like the best strategy is not to blindly update eudev, and
>> always check these things, before attempting an upgrade, and waiting
>> for it to catch up if/when it happens.
>
> Well, you shouldn't blindly update anything,

True... and I never do. I sync daily, then do an emerge -pvuDN world,
and note which packages want to be updated. I then track them, and after
a few days, if nothing has changed, update them.

For critical apps (boot/system related or server app related (ie,
postfix, dovecot, etc), I also always google for any problems with them
(gentoo+appver) right before updating.

I was always fairly careful in the past, but I started being anal about
it after I got bit by the minor mailman version bump a while (few
years?) ago that changed the locations of critical stuff (like, where
the lists were stored), thereby violating one of gentoo's cardinal rules
that minor version bumps don't make changes that break things, at least
not without lots of warning in the form of a detailed news item
explaining what needs to be done to avoid the breakage.

> but the issue here was eudev *not* being updated when the virtual
> was, and both cause and result were quite clear.

Right, but I was talking about not updating *anything* related to any
mission critical apps, and that would include the virtual/udev as well.

That said - shouldn't this be taken care of by the the virtual/udev
package itself? Shoudln't it keep track of what versions of udev *and*
eudev it supports, and warn you (via a [B]blocker)?

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Neil Bothwick
On Sun, 11 Aug 2013 11:52:26 -0400, Tanstaafl wrote:

> > but the issue here was eudev *not* being updated when the virtual
> > was, and both cause and result were quite clear.  
>
> Right, but I was talking about not updating *anything* related to any
> mission critical apps, and that would include the virtual/udev as well.
>
> That said - shouldn't this be taken care of by the the virtual/udev
> package itself? Shoudln't it keep track of what versions of udev *and*
> eudev it supports, and warn you (via a [B]blocker)?

There was a blocker (small b) because virtual/udev needed sys-fs/udev and
that gave a blocker that uninstalled eudev.


--
Neil Bothwick

The present never ages. Each moment is like a snowflake, unique,
unspoiled, unrepeatable, and can be appreciated in its surprisingness.

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

Re: Moving from old udev to eudev

Samuli Suominen-4
On 11/08/13 21:13, Neil Bothwick wrote:

> On Sun, 11 Aug 2013 11:52:26 -0400, Tanstaafl wrote:
>
>>> but the issue here was eudev *not* being updated when the virtual
>>> was, and both cause and result were quite clear.
>>
>> Right, but I was talking about not updating *anything* related to any
>> mission critical apps, and that would include the virtual/udev as well.
>>
>> That said - shouldn't this be taken care of by the the virtual/udev
>> package itself? Shoudln't it keep track of what versions of udev *and*
>> eudev it supports, and warn you (via a [B]blocker)?
>
> There was a blocker (small b) because virtual/udev needed sys-fs/udev and
> that gave a blocker that uninstalled eudev.
>
>

I believe it's 'b' if user doesn't have sys-fs/eudev in
/var/lib/portage/world, but 'B' if he does
As in, difference is soft and hard blocker depending if the wanted
implementation is recorded in the world file or not

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

tanstaafl-2
On 2013-08-11 2:38 PM, Samuli Suominen <[hidden email]> wrote:
> On 11/08/13 21:13, Neil Bothwick wrote:
>> There was a blocker (small b) because virtual/udev needed sys-fs/udev and
>> that gave a blocker that uninstalled eudev.

> I believe it's 'b' if user doesn't have sys-fs/eudev in
> /var/lib/portage/world, but 'B' if he does
> As in, difference is soft and hard blocker depending if the wanted
> implementation is recorded in the world file or not

Well, in my opinion, that just seems wrong. Why does it prefer udev, if
*neither* is in the world file?

In my opinion, it should be a 'B' blocker in both cases. It absolutely
should not automatically uninstall eudev and install udev, potentially
leaving the system in an unbootable state.

But... as long as the conflict is there (for  those who actually look
for such things) and I can deal with it appropriately - ie, if a small b
blocker and it wants to remove eudev and install udev, I just wait until ...

Hmmm... so is it eudev that would need to be updated to 'fix' this? Or
virtual/udev? Or both?

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Alan McKinnon-2
On 12/08/2013 12:19, Tanstaafl wrote:

> On 2013-08-11 2:38 PM, Samuli Suominen <[hidden email]> wrote:
>> On 11/08/13 21:13, Neil Bothwick wrote:
>>> There was a blocker (small b) because virtual/udev needed sys-fs/udev
>>> and
>>> that gave a blocker that uninstalled eudev.
>
>> I believe it's 'b' if user doesn't have sys-fs/eudev in
>> /var/lib/portage/world, but 'B' if he does
>> As in, difference is soft and hard blocker depending if the wanted
>> implementation is recorded in the world file or not
>
> Well, in my opinion, that just seems wrong. Why does it prefer udev, if
> *neither* is in the world file?
>
> In my opinion, it should be a 'B' blocker in both cases. It absolutely
> should not automatically uninstall eudev and install udev, potentially
> leaving the system in an unbootable state.
>
> But... as long as the conflict is there (for  those who actually look
> for such things) and I can deal with it appropriately - ie, if a small b
> blocker and it wants to remove eudev and install udev, I just wait until
> ...
>
> Hmmm... so is it eudev that would need to be updated to 'fix' this? Or
> virtual/udev? Or both?
>

It has to do with how virtuals work.

If you have the virtual in @world, and none of the packages that satisfy
the virtual are in world, then portage is free to do whatever it deems
correct to satisfy the virtual. This is what it did, and it is rather
important you understand why this is so.

If you have the virtual in world, and one of the packages that satisfy
the virtual are in world, then portage will not uninstall that package
and instead obey your instruction.

Portage does not work according to whatever we think ought to be
logical. Portage works according to the PMS spec. In this case, it did
what you asked, which is not what you wanted.



--
Alan McKinnon
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Samuli Suominen-4
In reply to this post by tanstaafl-2
On 12/08/13 13:19, Tanstaafl wrote:

> On 2013-08-11 2:38 PM, Samuli Suominen <[hidden email]> wrote:
>> On 11/08/13 21:13, Neil Bothwick wrote:
>>> There was a blocker (small b) because virtual/udev needed sys-fs/udev
>>> and
>>> that gave a blocker that uninstalled eudev.
>
>> I believe it's 'b' if user doesn't have sys-fs/eudev in
>> /var/lib/portage/world, but 'B' if he does
>> As in, difference is soft and hard blocker depending if the wanted
>> implementation is recorded in the world file or not
>
> Well, in my opinion, that just seems wrong. Why does it prefer udev, if
> *neither* is in the world file?

Because it's the default in virtual/udev
(/usr/portage/virtual/udev/udev-206-r2.ebuild)
As in, sys-fs/udev is the default of Gentoo

> In my opinion, it should be a 'B' blocker in both cases. It absolutely
> should not automatically uninstall eudev and install udev, potentially
> leaving the system in an unbootable state.

Portage doesn't work like that. If you step outside of the defaults, you
need to record them in your world. It's sort of the logical step to do.

> But... as long as the conflict is there (for  those who actually look
> for such things) and I can deal with it appropriately - ie, if a small b
> blocker and it wants to remove eudev and install udev, I just wait until
> ...
>
> Hmmm... so is it eudev that would need to be updated to 'fix' this? Or
> virtual/udev? Or both?

When new version of sys-fs/udev is released with incompabilities with
sys-fs/eudev, then new virtual version is created and dependencies
inside of it set to compatible versions
And if there is no compatible version available, then the version is set
to non-existing future-version number that /will be/ compatible with it
Which is exactly what happened earlier and will happen again

- Samuli

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

hasufell
In reply to this post by Samuli Suominen-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/02/2013 05:01 AM, Samuli Suominen wrote:

> On 02/08/13 05:48, Dale wrote:
>> Samuli Suominen wrote:
>>>
>>> Huh? USE="firmware-loader" is optional and enabled by default
>>> in sys-fs/udev Futhermore predictable network interface names
>>> work as designed, not a single valid bug filed about them.
>>>
>>> Stop spreading FUD.
>>>
>>> Looking forward to lastrite sys-fs/eudev just like
>>> sys-apps/module-init-tools already was removed as unnecessary
>>> later on.
>>
>> So your real agenda is to kill eudev?  Maybe it is you that is
>> spreading FUD instead of others.  Like others have said, udev was
>> going to cause issues, eudev has yet to cause any.
>
> Yes, absolutely sys-fs/eudev should be punted from tree since it
> doesn't bring in anything useful, and it reintroduced old bugs from
> old version of udev, as well as adds confusing to users. And no,
> sys-fs/udev doesn't have issues, in fact, less than what
> sys-fs/eudev has. Like said earlier, the bugs assigned to
> [hidden email] apply also to sys-fs/eudev and they have even more in
> their github ticketing system. And sys-fs/udev maintainers have to
> constantly monitor sys-fs/eudev so it doesn't fall too much behind,
> which adds double work unnecessarily. They don't keep it up-to-date
> on their own without prodding.
>
> Really, this is how it has went right from the start and the double
> work and user confusion needs to stop.
>
> - Samuli
>
>

* you are not telling the whole story about what happened and why the
fork came into life in the first place. It's not as simple as you seem
to suggest. There were good reasons at that point. Some changes were
merged by udev upstream and there are still more differences than you
point out. That has been discussed numerous of times.
* claiming that eudev didn't improve anything is wrong and can be proven
* that eudev is behind udev most of the time is correct
* that it causes tons of breakage for users... well, I don't know, not
for me since almost the beginning
* eudev will not be treecleaned until the gentoo devs who maintain it
agree (at best, it may be masked) and even if eudev will be obsolete
at some point, then it has been a success
* I don't understand why you add those rants all over different
mailing lists. I have seen it numerous of times and your precision
about explaining the situation does not improve. If you think that
people need to be warned about eudev, then you should provide a reason
to mask it or drop it back to ~arch. Anything else is not constructive
and causes confusion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSCMjkAAoJEFpvPKfnPDWz4/cH/1k5tyYetIZp0t+5BE2ytCFS
0FldL3IxIbOe16rfNP9LH5yqe/RnhabUbeja//rqhmMTeDGEEGbM/YgY6Tqo4q6Y
usUQueYpwsVFAL9AL93+CLyQMC3cS6F1EFBeP98vcvErqHFPu9N/k2CXCQTWVlbe
Vnbb+X9m2enso1rvSm/MBjtykJRzLw+Mq6gdVS9Pthb+UU78dX109z1Xtt9pSrUB
Fa/NLvmQELu5QOb3+m6XXas8SoXUgjvKZ3xGgRjVmeCITBpjfsIf4KdvW0gqzOdE
XjuIlNMPpLMZiWDV8yYMq2OVzRDwm8jTvSG/S4j45rHmBvTZj6km8979HAihtaQ=
=Gnsu
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

tanstaafl-2
In reply to this post by Alan McKinnon-2
On 2013-08-12 6:48 AM, Alan McKinnon <[hidden email]> wrote:
> On 12/08/2013 12:19, Tanstaafl wrote:
>> Hmmm... so is it eudev that would need to be updated to 'fix' this? Or
>> virtual/udev? Or both?

> It has to do with how virtuals work.
>
> If you have the virtual in @world, and none of the packages that satisfy
> the virtual are in world, then portage is free to do whatever it deems
> correct to satisfy the virtual. This is what it did, and it is rather
> important you understand why this is so.
>
> If you have the virtual in world, and one of the packages that satisfy
> the virtual are in world, then portage will not uninstall that package
> and instead obey your instruction.

Ok, I'm getting there...

I just confirmed that while I do have sys-fs/udev in world, but I *do*
have virtual/udev.

So, based on what Samuli said about sys-fs/udev being the gentoo default
(where is this documented by the way?), seems the simplest thing to do
is add sys-fs/eudev to @world, but is this really the most appropriate
'gentoo way'?

Or, maybe just remove virtual/udev from @world? Or both (add
sys-fs/eudev, remove virtual/udev)?

Actually, since udev/eudev are more appropriately @system packages, it
would make more sense to add them there - except @system is defined not
by a file but by the profile, and so would require a USE flag to define
this, but if I recall, adding a USE flag for this was decided against
(why I don't know)...

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

tanstaafl-2
On 2013-08-12 7:37 AM, Tanstaafl <[hidden email]> wrote:
> I just confirmed that while I do have sys-fs/udev in world, but I *do*
> have virtual/udev.

Crap... I meant I do NOT have sys-fs/eudev (or sys-fs/udev) in @world...

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Samuli Suominen-4
In reply to this post by hasufell
On 12/08/13 14:37, hasufell wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/02/2013 05:01 AM, Samuli Suominen wrote:
>> On 02/08/13 05:48, Dale wrote:
>>> Samuli Suominen wrote:
>>>>
>>>> Huh? USE="firmware-loader" is optional and enabled by default
>>>> in sys-fs/udev Futhermore predictable network interface names
>>>> work as designed, not a single valid bug filed about them.
>>>>
>>>> Stop spreading FUD.
>>>>
>>>> Looking forward to lastrite sys-fs/eudev just like
>>>> sys-apps/module-init-tools already was removed as unnecessary
>>>> later on.
>>>
>>> So your real agenda is to kill eudev?  Maybe it is you that is
>>> spreading FUD instead of others.  Like others have said, udev was
>>> going to cause issues, eudev has yet to cause any.
>>
>> Yes, absolutely sys-fs/eudev should be punted from tree since it
>> doesn't bring in anything useful, and it reintroduced old bugs from
>> old version of udev, as well as adds confusing to users. And no,
>> sys-fs/udev doesn't have issues, in fact, less than what
>> sys-fs/eudev has. Like said earlier, the bugs assigned to
>> [hidden email] apply also to sys-fs/eudev and they have even more in
>> their github ticketing system. And sys-fs/udev maintainers have to
>> constantly monitor sys-fs/eudev so it doesn't fall too much behind,
>> which adds double work unnecessarily. They don't keep it up-to-date
>> on their own without prodding.
>>
>> Really, this is how it has went right from the start and the double
>> work and user confusion needs to stop.
>>
>> - Samuli
>>
>>
>
> * you are not telling the whole story about what happened and why the
> fork came into life in the first place. It's not as simple as you seem

True, I didn't mention people were needlessly unwilling to join the
Gentoo udev team despite being invited to.

> to suggest. There were good reasons at that point. Some changes were
> merged by udev upstream and there are still more differences than you
> point out. That has been discussed numerous of times.
> * claiming that eudev didn't improve anything is wrong and can be proven

I can easily prove eudev is nothing but udev and deleted code, plus
restored broken 'rule generator', plus useless kept static nodes
creation which was moved to kmod, plus needlessly changed code for
uclibc support -- uclibc now has the functions udev needs.

> * that eudev is behind udev most of the time is correct
> * that it causes tons of breakage for users... well, I don't know, not
> for me since almost the beginning
> * eudev will not be treecleaned until the gentoo devs who maintain it
> agree (at best, it may be masked) and even if eudev will be obsolete
> at some point, then it has been a success
> * I don't understand why you add those rants all over different
> mailing lists. I have seen it numerous of times and your precision
> about explaining the situation does not improve. If you think that
> people need to be warned about eudev, then you should provide a reason
> to mask it or drop it back to ~arch. Anything else is not constructive
> and causes confusion.

True, it won't be dropped for long as people are maintaining it. That's
how maintainership works.
But trying to lie to people it's somehow solving something currently is
annoying as 'ell and should be corrected where seen.

- Samuli


Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Alan McKinnon-2
In reply to this post by tanstaafl-2
On 12/08/2013 13:37, Tanstaafl wrote:

> On 2013-08-12 6:48 AM, Alan McKinnon <[hidden email]> wrote:
>> On 12/08/2013 12:19, Tanstaafl wrote:
>>> Hmmm... so is it eudev that would need to be updated to 'fix' this? Or
>>> virtual/udev? Or both?
>
>> It has to do with how virtuals work.
>>
>> If you have the virtual in @world, and none of the packages that satisfy
>> the virtual are in world, then portage is free to do whatever it deems
>> correct to satisfy the virtual. This is what it did, and it is rather
>> important you understand why this is so.
>>
>> If you have the virtual in world, and one of the packages that satisfy
>> the virtual are in world, then portage will not uninstall that package
>> and instead obey your instruction.
>
> Ok, I'm getting there...
>
> I just confirmed that while I do have sys-fs/udev in world, but I *do*
> have virtual/udev.
>
> So, based on what Samuli said about sys-fs/udev being the gentoo default
> (where is this documented by the way?), seems the simplest thing to do
> is add sys-fs/eudev to @world, but is this really the most appropriate
> 'gentoo way'?
>
> Or, maybe just remove virtual/udev from @world? Or both (add
> sys-fs/eudev, remove virtual/udev)?
>
> Actually, since udev/eudev are more appropriately @system packages,


This is incorrect. @system is the minimal set of packages for a Gentoo
system to work at all, and consists mostly of baselayout, toolchain and
various packages used by the toolchain.

A Gentoo system does NOT have to have a device manager to function, you
can accomplish that easily with static device nodes.

What is in @system is virtual/dev-manager which has this RDEPEND:

RDEPEND="|| (
                virtual/udev
                sys-apps/busybox[mdev]
                sys-fs/devfsd
                sys-fs/static-dev
                sys-freebsd/freebsd-sbin
        )"

So you are free to install any of those methods you choose and thereby
have working device nodes.

To back up what Samuli said, if you want to GUARANTEE a certain device
manager then you need to put it in @world, just like you already do for
all the other packages you have. udev is in no way special in this regard.


> it
> would make more sense to add them there - except @system is defined not
> by a file but by the profile, and so would require a USE flag to define
> this, but if I recall, adding a USE flag for this was decided against
> (why I don't know)...
>


--
Alan McKinnon
[hidden email]


123456