The lowest version of eudev in the tree is 3.1.5. Why would someone use eudev-1.10 then?

If there was a good reason, it could have been preserved. It wasn't. You want something not in the tree any more -> your responsibility. No question. But I am curious, why that ancient eudev? What is wrong with the newer?

Edit: I just had a look at the 1.10 release: "Aug 22, 2014, 614 commits to master since this tag" That's quite some change I daresay..._________________Important German:

"Aha" - German reaction to pretend that you are really interested while giving no f*ck.

"Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.

Not it's still a fault
You should use a virtual/udev::local that is hack to accept eudev-1.10 as valid choice in its RDEPEND
[

Good idea. If i ever get an alternate, I can just change my local ebuild. Actually, mdev works fine but some other packages want the hardware data base that udev generates.

As I think about such a package, let's call it smalldev, would hard depend on mdev and have a little code to run after boot and hot plugging to generate the table. It wouldn't have all those udev rules, but I don't use them anyway.

The lowest version of eudev in the tree is 3.1.5. Why would someone use eudev-1.10 then?

I masked everything greater than 1.99 but didn't make a note why. Was there a 2.x series with problems? The only thing I see in the ebuild is

Code:

ewarn
ewarn "As of 2013-01-29, ${P} provides the new interface renaming functionality,"
ewarn "as described in the URL below:"
ewarn "https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames"
ewarn
ewarn "This functionality is enabled BY DEFAULT because eudev has no means of synchronizing"
ewarn "between the default or user-modified choice of sys-fs/udev. If you wish to disable"
ewarn "this new iface naming, please be sure that /etc/udev/rules.d/80-net-name-slot.rules"
ewarn "exists: touch /etc/udev/rules.d/80-net-name-slot.rules"
ewarn

And i take care of that with " net.ifnames=0" on the kernel command line anyway.
I do use those rules to rename eth0 and eth1 to lan0 and wan0 on my router box. I run 1.10 there also so apparently the capability was there already.
So i really can't answer your question. Can you answer "Why would someone use anything later than eudev-1.10 then?" ?

So, if I understand you two correctly, you both brought the virtual/udev annoyance upon yourselves without any benefit in return, right?

I must admit that I am a bit disappointed now. I thought I'd be given some insight about problems with eudev 2+ that I wasn't aware of...

But of course the reason "personal choice" is always sound and valid, no matter who else might find it irresponsible, unlogical or whatever.

Tony0945 wrote:

Can you answer "Why would someone use anything later than eudev-1.10 then?" ?

First reason would be bugfixes. There certainly have been issues fixed in the meantime.
Second reason would be to not have such annoyances with dependency hell I had to manually fix, keep and maintain in a local overlay without getting anything in return.

If there is nothing wrong with the newer version, I see no reason to keep the old one forcefully installed with such a high cost.
But as stated above, personal choice always matters more. So if you two trust your choice back then, even if you can remember the reasoning, and are willing to "keep the pieces", then I say: "Why not?" _________________Important German:

"Aha" - German reaction to pretend that you are really interested while giving no f*ck.

"Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.

First reason would be bugfixes. There certainly have been issues fixed in the meantime.

It would be nice to see these in the package notes instead of just "version bump". At least a link to upstream revision history.

This is one reason why I locked openrc. There were feature updates that I didn't like. Like automatically loading all modules. Why bother building something as a module if it's always going to be loaded? And tmpfiles. Adding systemd locations. The init system is important. It's not just another application where unexpected quirks can be tolerated. Similarly with bash that I've locked because an unannounced change broke my scripts. I did keep that version after reading a forum discussion on how to fix it. Then I locked it. Too important for surprises.

So really there are more than two reasons to change a packages code:

1. New capability
2. Bugfixes
3. Upstream developer just decided to recode everything his way.
4. Upstream developer decided to change the API.
5. To make it more compatible with systemd because "wave of the future"
Upstream meaning Gentoo dev for gentoo projects.

#2 is always valid.
#1 is valid if the new capability is wanted or not harmful or optional.
#3 and #4 are rarely valid and should really be a forked package rather than just a version change.
#5 for me is never valid, YMMV

I could take it on faith, but past experience has taught me not to. I don't want to name names and get into a flame war, but their are three gentoo devs whose motives and skill I don't trust at all. There are two more that I don't think have bad motives but have made too many mistakes in the past through either inattention or poor process that I always wait a month to see if someone is going to report a problem in the forums, but I think their hearts are pure. The rest of the devs I think are top notch and I'm glad we have them.

EDIT:
So, again, "What changed between eudev 1 and eudev 3 and why?" I would think that our eudev devs were following the upstream udev changes. I trust RedHat as much as (or even less than) Microsoft, so why should I blindly accept their changes?

So, if I understand you two correctly, you both brought the virtual/udev annoyance upon yourselves without any benefit in return, right?

Annoyance? I never said I was annoyed with any of it. virtual/udev-215 is still in the gentoo repository, true I did copy it to my local and have it masked past that point, but I routinely do that with lots of packages, and over time it's kept me from starting threads asking why xyz broke when stuff got promoted to stable that shouldn't have been. *shrugs*

you see, they depends on virtual/udev only, or depends on a version but always >=
following JRG's tips for guys with a brain
you could name it virtual/udev-9999::local making the mask effective while not having any mask set ; which will remove the need to update it each time a new virtual/udev-version-higher-than-yours enter the tree.

I blocked bash-completion and bash for a while because the latest "stable" version did some weirdness on my system,
don't remember the details as it was a year or two back.

Just because something is released stable doesn't mean it can't/won't cause problems.

One of the font packages, for several releases, has given me fuzzy looking fonts on both the console and urxvt,
and the fonts that I use aren't from that package.
I never have figured out why, as the easy answer was just to block at a particular version of that package.
I even googled when it first showed and some people on other distros were having the same problem.

Yes, I could fix it by not having the fonts on my system, but the older worked fine, so I went with that option.

As far as less than sanguine advice like "fix your scripts to not depend on uncertain defaults"
I consider that very boorish trolling, maybe it's something they're putting in the water in that country. *shrugs*

I blocked bash-completion and bash for a while because the latest "stable" version did some weirdness on my system,
don't remember the details as it was a year or two back.

While may have been longer ago than that, I recall some really awful changes to bash tab completion regarding variables, for example if you had a variable set to a path. At one point it hitting tab with a variable in your command started escaping the $ with \. They fixed that, however I believe that at one point the tab would expand such a variable, and that behavior never came back.

I asked my question because I was hoping for details on specific broken versions, what bad behaviors those had, and so on - not to start a fight over whether any particular change was good or whether it was proper for users to depend on old defaults. I too recall the annoying terminal-goes-to-no-echo mode problem, and I hadn't thought about it until Ant P.'s post, but it seems like it hasn't hit me in a while, after a long period where it was quite annoying. Also, like tld mentions, the newer rules for tab interaction with variables are worse than the older ones.