Is eudev alive and default?

[UlvHare]

After nervous yesterday update (see this thread) I also saw [bug=698726]a bug[/bug] where developer said:

It {stable tree} simply doesn't support eudev anymore. This may change in the future but doesn't change the fact that eudev is barely alive.

Yes? Really?! eudev was default (emerged by deps). Maybe my system is wrong configured?
Please, tell me what is the right choice for udev in my situation? Desktop, amd64 mostly stable, KDE.

Code: Select all

alver@hare ~ $ eselect profile show
Current /etc/portage/make.profile symlink:
  default/linux/amd64/17.1/desktop/plasma

[asturm]

You can pick eudev or udev, they are easily interchangeable. The default may change back to udev in the future.

[Fitzcarraldo]

The default may change back to udev in the future.

So, back to extracting udev code from systemd package (SRC_URI="https://github.com/systemd/systemd/arch ... _P}.tar.gz"), then?

Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-10-28 14:50:43 UTC

(In reply to Anton Bolshakov from comment #8)
> The current stable tree is broken. Please sync stabilization and do it at
> one go.

It is not broken. It simply doesn't support eudev anymore. This may change in the future but doesn't change the fact that eudev is barely alive.

Comment 10 Anthony Basile gentoo-dev 2019-10-28 16:45:45 UTC

(In reply to Michał Górny from comment #9)
> (In reply to Anton Bolshakov from comment #8)
> > The current stable tree is broken. Please sync stabilization and do it at
> > one go.
>
> It is not broken. It simply doesn't support eudev anymore. This may change
> in the future but doesn't change the fact that eudev is barely alive.

eudev is being maintained.

Gentoo developer Anthony Basile is one of the eudev committers: https://github.com/gentoo/eudev

What is the future of eudev?

[asturm]

The default may change back to udev in the future.

So, back to extracting udev code from systemd package, then?

That's how it has worked all the time.

[Fitzcarraldo]

The default may change back to udev in the future.

So, back to extracting udev code from systemd package, then?

That's how it has worked all the time.

I know. Apparently you missed my point.

sys-fs/eudev:

Code: Select all

SRC_URI="https://dev.gentoo.org/~blueness/${PN}/${P}.tar.gz"

If eudev "is barely alive" according to Michał Górny, then there would effectively be no choice any more if it ceases to exist:

sys-fs/udev:

Code: Select all

SRC_URI="https://github.com/systemd/systemd/archive/v${MY_PV}/${MY_P}.tar.gz"

sys-fs/systemd:

Code: Select all

SRC_URI="https://github.com/systemd/systemd/archive/v${MY_PV}/${MY_P}.tar.gz"

virtual/udev would become:

Code: Select all

RDEPEND="
	!systemd? ( >=sys-fs/udev-217:0 )
	systemd? ( >=sys-apps/systemd-217:0 )"

What is the future of eudev?

[Anon-E-moose]

What is the future of eudev?

As long as someone maintains it, it will exist.
Having said that, whether it will exist as a mainstream package in gentoo is another matter, at least if some devs have their way.
I'm sure that a few devs would like it to disappear, then we could view yet another post from LP about "gentoo's wakeup call".

Edit to add: I still run sys-fs/eudev-1.10 and it works well for my needs, and I dare say it would work well for 90%+ of those using it.
I did have to modify the source (to update to the newer glibc by adding sys/sysmacros.h and stdint.h) but it works well.

[asturm]

I don't think your person of interest actually cares what we do.

sys-fs/udev:

Code: Select all

SRC_URI="https://github.com/systemd/systemd/archive/v${MY_PV}/${MY_P}.tar.gz"

sys-fs/systemd:

Code: Select all

SRC_URI="https://github.com/systemd/systemd/archive/v${MY_PV}/${MY_P}.tar.gz"

Is it philosophically important which tarball you are taking udev from?

What is the future of eudev?

I don't think it goes away, but as default it will no longer be a sane choice if there is another prolonged period of brokenness.

[UlvHare]

Thank you all!
Concluding that eudev is still alive and I can heave a sigh of relief.
I'm afraid of sudden changes and don't trust systemd, Gnome >= 3, and Pottering
I like Gentoo mostly for 2 things: stability (after ArchLinux) and intelligibility (after Debian and my attempts to customize it). Yes, tempora mutantur, we lost KDE4 for example, but there is a good tradidtion in Gentoo -- to announce big changes during 'eix-sync && emerge -uDpvN world'. So the reason of starting this thread was my paranoia (breaking change -> secret Pottering invasion)

[Fitzcarraldo]

Is it philosophically important which tarball you are taking udev from?

If you are referring to the two tarballs:

sys-fs/eudev:

Code: Select all

SRC_URI="https://dev.gentoo.org/~blueness/${PN}/${P}.tar.gz"

sys-fs/systemd and sys-fs/udev:

Code: Select all

SRC_URI="https://github.com/systemd/systemd/archive/v${MY_PV}/${MY_P}.tar.gz"

then it is not a philosophical issue, because their contents are not identical. eudev is modified to remove any dependence on the remaining systemd code, which I am not using, and I therefore prefer sys-fs/eudev over sys-fs/udev. To have to download systemd in its entirety in order to obtain purely the udev component is less preferable in my opinion. Additionally, sys-fs/eudev provides at least some semblance of autonomy (I am aware eudev has to shadow systemd-udev in principle).

[GDH-gentoo]

another prolonged period of brokenness.

So, was eudev's 'brokenness' just this, or is there more? Was failure to make pkg-config --modversion libudev output a sufficiently high number to keep mutter's build system happy in a timely manner the whole reason that makes mgorny say that eudev is "barely alive"? I'm sure that we could find bugs in Gentoo's tracker that have been sitting unattended for longer. This just looks like overreaction.

Despite bumping the value of the "Version" line in libudev's .pc file in every systemd release, judging by the commit logs in the GitHub repository, the library itself doesn't seem to have had any user-facing changes at least this year, and judging by symbol versioning, its ABI hasn't changed since 2014. So there seems to be no reason to think eudev's library had an actual incompatibility, whatever happened to be the particular 'systemd compatibility release number' they picked for the .pc file.

[Ant P.]

This just looks like overreaction.

Agreed. And it's 100% consistent with past behaviour too, which is worse. Developers ought to be smarter than a machine-learning script hooked up to a delete button.

[i4dnf]

Developers ought to be smarter than a machine-learning script hooked up to a delete button.

I somehow doubt it's a case of too little smartness, rather than FUD fitting their agenda.

[asturm]

Sigh. Conspiracy mode again, I'm out.

[krinn]

Sigh. Conspiracy mode again, I'm out.

So it's not conspiracy but just stupidity?

[Anon-E-moose]

Sigh. Conspiracy mode again, I'm out.

So it's not conspiracy but just stupidity?

Apologitics can only stretch so far.

[Hu]

Could we back off on the developers a bit? If they screw up, it's fine to call them on it, but please do so based on specific facts that they reasonably should have known at the time they screwed up. Remember that as a metadistribution, Gentoo is a complicated system, and give them the benefit of the doubt in complicated situations. Some mistakes may be simple inability to adequately test, rather than malicious scheming. I would have liked to see a straight answer to GDH-gentoo's question from someone with the background to address it without speculation.

GDH-gentoo's query looks to me like a good example of a fair question. It identifies a specific problem that mgorny might have meant, asks whether that was the sole basis for mgorny's comment, and presents reasons why that problem appears not to warrant that comment. It does not presuppose that the comment was made with ulterior motives. It leaves an opening for someone to present a better justification, such as some more severe bug of which GDH-gentoo was unaware, or evidence that a series of minor bugs have stacked up to become an ongoing nuisance.

[Anon-E-moose]

Speaking just for me, I find it easier to to discount a mistake if there isn't a history of questionable decisions along with a dismissal of the user base (previous comments about forum users).

The failure here is clearly QA not the developer of the package.
What should have been done, is a notice to the package dev that the pkgconfig version level needed to be synced properly and hold off on updating the virtual.
Instead we have pronouncements that eudev is broken and not being maintained (both of which were false) and on life support.
With this it's hard to see this as anything other than an attack on eudev (a viable udev replacement), and with such blatant statements,
it naturally leads to conjecture as to why these statements are made.

I too would like to see GDH's query answered, but that didn't happen, nor do I expect it to be answered.

[Fitzcarraldo]

...

+1

[krinn]

Some mistakes may be simple inability to adequately test

Sorry Hu, his comment #9 is within a bug that show him a testing result of his changes.
So we could had expect him to actually shown excuses and a fix to his "mistake" by the time that comment was made

rather than malicious scheming.

Instead, he is asserting eudev is no more support and without proper sources showing that, i assume it's his own agenda and not a Gentoo decision
Then, he is making a false assertion that udev is not maintain, and i prefer trust the eudev maintainer than him on this one
Or were these again "mistakes" or more signs of what he was trying to do?

[Hu]

Speaking just for me, I find it easier to to discount a mistake if there isn't a history of questionable decisions along with a dismissal of the user base (previous comments about forum users).

That's fair. As a convenience to readers, a brief recap of a developer's past mistakes would be helpful to show that you have good reason to distrust a particular person's comments. (What you wrote here is a fine recap for that purpose.) Not everyone will remember which people have earned distrust. For my part, I remember that mixing Tony and asturm in the same thread is a bad idea, that several people are unhappy with Hubbs over openrc, that asturm is one of the few developers I see post on the forums regularly, and that's about it. I don't keep straight whether asturm is a good developer or not, much less which of the silent developers I trust/distrust.

The failure here is clearly QA not the developer of the package.
What should have been done, is a notice to the package dev that the pkgconfig version level needed to be synced properly and hold off on updating the virtual.

I haven't checked whether facts elsewhere support this characterization, but assuming they do, I agree with the criticism that the virtual should not have been changed in a way that lets users hit a build break. I would also say that some fault goes to the udev developers for bumping their version number without actually changing anything, and a fair bit to the mutter developers for testing a version number (and the wrong one at that) instead of testing for the feature they need. Inspecting a version number and deciding that declares the presence/absence of some particular feature is almost always wrong.

Instead we have pronouncements that eudev is broken and not being maintained (both of which were false) and on life support.
With this it's hard to see this as anything other than an attack on eudev (a viable udev replacement), and with such blatant statements,
it naturally leads to conjecture as to why these statements are made.

Yes, there might be an ulterior motive here. It could also just be frustration on the part of the Gentoo developers. For some things I work with, I have been burned repeatedly by certain design flaws that I can't fix, to the point that any time I get a report that things are not perfect, I assume the thing that has burned me before has failed, yet again. I still investigate to see if that component is actually the guilty one, but my first thought on receiving the report is that it probably will be the guilty party. A similar problem could apply here: the eudev project may not be responsive enough for others' taste (mgorny et al.), so now any minor failure or delay is magnified. GDH-gentoo was inquiring whether the complaint had more basis than is evidenced so far, which, if answered, would have supported or contradicted conjecture about ulterior motives.

I too would like to see GDH's query answered, but that didn't happen, nor do I expect it to be answered.

It might have been answered if asturm had not been chased off by some of the subsequent comments. I read his most recent post here as deciding that no one wanted to hear his side of the story, so it was not worth his time to post it.

Sorry Hu, his comment #9 is within a bug that show him a testing result of his changes.

I was thinking more in the sense that the developer changed a dependency that he knew he couldn't test, but he thought it looked reasonable, and committed it anyway. Looking at the bug you linked, I don't think that hypothetical applies well here.

So we could had expect him to actually shown excuses and a fix to his "mistake" by the time that comment was made

Some people never admit fault, even when the facts are clear. I don't know if the people involved here are in that category.

rather than malicious scheming.

Instead, he is asserting eudev is no more support and without proper sources showing that, i assume it's his own agenda and not a Gentoo decision

This could be poor phrasing, though I admit it doesn't look good. Hypothetically, It simply doesn't support eudev anymore. could be a direct statement of fact: the stable tree dropped support for eudev because the stable tree had acquired a dependency on features that stable eudev didn't offer. In the case that a new package version depends on new udev features, the developers have limited options:

• Refuse to make the consuming packages stable until all udev forks support that feature, even if that holds the package in unstable for an extended period.
• Patch out the dependency in the consuming package.
• Patch in the feature in all the udev forks.
• Declare some udev forks "unsupported", drop them from the dependency tree, and proceed with the consuming package.

We saw this play out before with GNOME's obnoxious systemd dependence. Sometimes the feature is too deeply wired into the consuming package to be removed, and too complicated to patch in to the providing package. Remember that some Gentoo developers are not (and do not pretend to be!) qualified to actually take over for the authors of the packages that the Gentoo developer maintains. When that happens, the Gentoo developer is just a messenger for whatever good or bad changes upstream makes.

Then, he is making a false assertion that udev is not maintain, and i prefer trust the eudev maintainer than him on this one
Or were these again "mistakes" or more signs of what he was trying to do?

The linked eudev stabilization bug states There are only a few minor fixes over the 3.2.5 version which has been stable forever. Its ready for stabilization., which might be read as being that eudev is a slow-moving project.

To recap, I am not here to claim that nobody has ulterior motives, nor to claim that nobody made mistakes. I am here to ask that you give people the benefit of the doubt and, when there is no reasonable doubt, that your criticisms of them sound reasonable to someone who has no idea who any of the involved parties are. Alleging ulterior motives without the supporting facts like those referenced in the posts responding to me can lead outside readers to the wrong conclusion, and lead inside readers (such as asturm) to simply walk away without presenting potentially interesting information.

[Anon-E-moose]

AFAIK asturm has nothing to do with *udev.

Code: Select all

    Freedesktop Project
    KDE Project
     Developer
    Office project
     member
    Proxy Maintainers
     Member

Unless mentioning FDO, means he's conversant on all of their projects, but I doubt that.
He may know some things about eudev, but I don't think he's in a position to speak with authority on it.

Anyway, it seems that eudev is back on the menu ... for the moment.

Edit to add: But for those interested in continuing to use eudev, they might keep a closer eye on it and maybe keep a backup in the local repo, just in case.

ETA2: I'm not trying to argue with you Hu, I know your intentions are good.

AFA asturm, I like it when he responds to posts with helpful information, I don't like it so much when he's deliberately trying to stir up trouble, though I do understand he's only human. Interestingly he ignored GDH's post to respond to the 2 posts below it, before he "walked off". He had a chance to respond in a thoughtful manner. His previous responses in this thread didn't seem to be helpful, but more justification for the route that was taken re the virtual ebuild/eudev.
(changed from krinn to 2 posts )