# Andreas K. Hüttel <dilfridge@gentoo.org> (2023-09-11)
# Dead project accumulating open bugs and incompatibilities.
# No maintainer commits since February 2021.
# Bugs 673834, 713106, 753134, 667686, 771705, 668880, 770358, 851255,
# 711462, 904741, ... Removal in 30 days.
sys-fs/eudev
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:
Upstream is maintained still.
https://github.com/eudev-project/eudev
No, it's not.
Upstream is maintained still.
https://github.com/eudev-project/eudev
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" dilfridge@gentoo.org wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:
Upstream is maintained still.
https://github.com/eudev-project/eudev
No, it's not.
Based on what? It has several commits this year and is currently
working on both of my systems. Is there something specific showing why
its not maintained?
Here.
https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html
Sent with Proton Mail secure email.
------- Original Message -------
On Monday, September 11th, 2023 at 5:42 PM, orbea <orbea@riseup.net>
wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" dilfridge@gentoo.org wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:
Upstream is maintained still.
https://github.com/eudev-project/eudev
No, it's not.
Based on what? It has several commits this year and is currently
working on both of my systems. Is there something specific showing
why its not maintained?
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is currently
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
working on both of my systems. Is there something specific showing why
its not maintained?
.
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is currently
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
working on both of my systems. Is there something specific showing why
its not maintained?
.
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project was established on 2021-09-14 by Alpine, Devuan and Gentoo contributors (alphabetical order).
It seems to have a upstream that is active but no one is maintaining it
on Gentoo. Basically, it needs a Gentoo maintainer now. It would seem given the time span that no one wants to take it.Â
Like others, I use it but didn't know it wasn't maintained anymore. I
hope someone will step up but if not, looks like we have to use udev.Â
Dale
:-)Â :-)Â
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is currently
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
working on both of my systems. Is there something specific showing why
its not maintained?
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project was
established on 2021-09-14 by Alpine, Devuan and Gentoo contributors
(alphabetical order).
It seems to have a upstream that is active but no one is maintaining it
on Gentoo. Basically, it needs a Gentoo maintainer now. It would
seem given the time span that no one wants to take it.Â
Like others, I use it but didn't know it wasn't maintained anymore. I
hope someone will step up but if not, looks like we have to use udev.Â
No, see the linked bugs. Someone has to actually make it compatible
with the tags API which software is starting to use.
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is currently
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
working on both of my systems. Is there something specific showing
why its not maintained?
.
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project was established on 2021-09-14 by Alpine, Devuan and Gentoo contributors (alphabetical order).
It seems to have a upstream that is active but no one is
maintaining it on Gentoo. Basically, it needs a Gentoo maintainer
now. It would seem given the time span that no one wants to take
it.Â
Like others, I use it but didn't know it wasn't maintained anymore.
I hope someone will step up but if not, looks like we have to use
udev.Â
No, see the linked bugs. Someone has to actually make it compatible
with the tags API which software is starting to use.
Dale
:-)Â :-)Â
orbea <orbea@riseup.net> writes:
On Mon, 11 Sep 2023 21:31:30 +0100
Sam James <sam@gentoo.org> wrote:
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is currently
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
working on both of my systems. Is there something specific showing
why its not maintained?
.
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project was
established on 2021-09-14 by Alpine, Devuan and Gentoo contributors
(alphabetical order).
It seems to have a upstream that is active but no one is
maintaining it on Gentoo. Basically, it needs a Gentoo maintainer
now. It would seem given the time span that no one wants to take
it.
Like others, I use it but didn't know it wasn't maintained anymore.
I hope someone will step up but if not, looks like we have to use
udev.
No, see the linked bugs. Someone has to actually make it compatible
with the tags API which software is starting to use.
I think its only a matter of time.
https://github.com/eudev-project/eudev/pull/253
I'll apply the patch and test the builds if it helps, but I don't know
about testing the runtime functionality of libgudev.
Someone has to then bother reviewing it, merging it, releasing it, and ideally updating eudev for other stuff like this.
Also note that the PR is a hack rather than a full implementation
of the functionality anyway, which may lead to runtime misbehaviour.
On Mon, 11 Sep 2023 21:31:30 +0100
Sam James <sam@gentoo.org> wrote:
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is currently
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
working on both of my systems. Is there something specific showing
why its not maintained?
.
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project was
established on 2021-09-14 by Alpine, Devuan and Gentoo contributors
(alphabetical order).
It seems to have a upstream that is active but no one is
maintaining it on Gentoo. Basically, it needs a Gentoo maintainer
now. It would seem given the time span that no one wants to take
it.Â
Like others, I use it but didn't know it wasn't maintained anymore.
I hope someone will step up but if not, looks like we have to use
udev.Â
No, see the linked bugs. Someone has to actually make it compatible
with the tags API which software is starting to use.
I think its only a matter of time.
https://github.com/eudev-project/eudev/pull/253
I'll apply the patch and test the builds if it helps, but I don't know
about testing the runtime functionality of libgudev.
Dale
:-)Â :-)Â
11.09.2023 22:21, Sam James пишет:
orbea <orbea@riseup.net> writes:
On Mon, 11 Sep 2023 21:31:30 +0100Someone has to then bother reviewing it, merging it, releasing it,
Sam James <sam@gentoo.org> wrote:
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is currently
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
working on both of my systems. Is there something specific showing >>>>>> why its not maintained?
.
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project was
established on 2021-09-14 by Alpine, Devuan and Gentoo contributors
(alphabetical order).
It seems to have a upstream that is active but no one is
maintaining it on Gentoo. Basically, it needs a Gentoo maintainer
now. It would seem given the time span that no one wants to take
it.
Like others, I use it but didn't know it wasn't maintained anymore.
I hope someone will step up but if not, looks like we have to use
udev.
No, see the linked bugs. Someone has to actually make it compatible
with the tags API which software is starting to use.
I think its only a matter of time.
https://github.com/eudev-project/eudev/pull/253
I'll apply the patch and test the builds if it helps, but I don't know
about testing the runtime functionality of libgudev.
and
ideally updating eudev for other stuff like this.
Of course. Just like any other PR to any other project :) What's your point?
Also note that the PR is a hack rather than a full implementation
of the functionality anyway, which may lead to runtime misbehaviour.
And that's fine for programs which don't make use of the new API.
orbea <orbea@riseup.net> writes:
On Mon, 11 Sep 2023 21:31:30 +0100
Sam James <sam@gentoo.org> wrote:
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is currently
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
working on both of my systems. Is there something specific
showing why its not maintained?
.
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project
was established on 2021-09-14 by Alpine, Devuan and Gentoo
contributors (alphabetical order).
It seems to have a upstream that is active but no one is
maintaining it on Gentoo. Basically, it needs a Gentoo
maintainer now. It would seem given the time span that no one
wants to take it.Â
Like others, I use it but didn't know it wasn't maintained
anymore. I hope someone will step up but if not, looks like we
have to use udev.Â
No, see the linked bugs. Someone has to actually make it compatible
with the tags API which software is starting to use.
I think its only a matter of time.
https://github.com/eudev-project/eudev/pull/253
I'll apply the patch and test the builds if it helps, but I don't
know about testing the runtime functionality of libgudev.
Someone has to then bother reviewing it, merging it, releasing it, and ideally updating eudev for other stuff like this.
Also note that the PR is a hack rather than a full implementation
of the functionality anyway, which may lead to runtime misbehaviour.
Dale
:-)Â :-)Â
Sam James wrote:
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is currently
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
working on both of my systems. Is there something specific showing why >>>> its not maintained?
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project was
established on 2021-09-14 by Alpine, Devuan and Gentoo contributors
(alphabetical order).
It seems to have a upstream that is active but no one is maintaining it
on Gentoo. Basically, it needs a Gentoo maintainer now. It would
seem given the time span that no one wants to take it.Â
Like others, I use it but didn't know it wasn't maintained anymore. I
hope someone will step up but if not, looks like we have to use udev.Â
No, see the linked bugs. Someone has to actually make it compatible
with the tags API which software is starting to use.
It seems there is work still ongoing to that end: https://github.com/eudev-project/eudev/issues/249
A quick look at the bug list in the original announcement today, they
appear to almost all be bugs for Gentoo maintainers to address rather than upstream, and one or two it's questionable if they are actually bugs.
I think it is a rather large stretch to claim that upstream is dead, the evidence just doesn't show that.
So what's the situation with the current Gentoo maintainers? Have they disappeared? I often see on here packages being offered up for grabs. Why hasn't there been a call to give others the opportunity to volunteer as maintainers rather than going straight to last riting the package? Or has that happened and I've missed it, in which case I apologise.
Alexey Sokolov <alexey+gentoo@asokolov.org> writes:
11.09.2023 22:21, Sam James пишет:
orbea <orbea@riseup.net> writes:
On Mon, 11 Sep 2023 21:31:30 +0100Someone has to then bother reviewing it, merging it, releasing it,
Sam James <sam@gentoo.org> wrote:
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is currently >>>>>>> working on both of my systems. Is there something specific showing >>>>>>> why its not maintained?
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
.
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project was >>>>>> established on 2021-09-14 by Alpine, Devuan and Gentoo contributors >>>>>> (alphabetical order).
It seems to have a upstream that is active but no one is
maintaining it on Gentoo. Basically, it needs a Gentoo maintainer >>>>>> now. It would seem given the time span that no one wants to take >>>>>> it.
Like others, I use it but didn't know it wasn't maintained anymore. >>>>>> I hope someone will step up but if not, looks like we have to use >>>>>> udev.
No, see the linked bugs. Someone has to actually make it compatible
with the tags API which software is starting to use.
I think its only a matter of time.
https://github.com/eudev-project/eudev/pull/253
I'll apply the patch and test the builds if it helps, but I don't know >>>> about testing the runtime functionality of libgudev.
and
ideally updating eudev for other stuff like this.
Of course. Just like any other PR to any other project :) What's your point?
I don't know what you mean. My point is none of that has been happening.
Also note that the PR is a hack rather than a full implementation
of the functionality anyway, which may lead to runtime misbehaviour.
And that's fine for programs which don't make use of the new API.
and? Someone has to actually check that?
11.09.2023 22:35, Sam James пишет:
Alexey Sokolov <alexey+gentoo@asokolov.org> writes:
11.09.2023 22:21, Sam James пишет:
orbea <orbea@riseup.net> writes:
On Mon, 11 Sep 2023 21:31:30 +0100Someone has to then bother reviewing it, merging it, releasing it,
Sam James <sam@gentoo.org> wrote:
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is currently >>>>>>>> working on both of my systems. Is there something specific showing >>>>>>>> why its not maintained?
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
.
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project was >>>>>>> established on 2021-09-14 by Alpine, Devuan and Gentoo contributors >>>>>>> (alphabetical order).
It seems to have a upstream that is active but no one is
maintaining it on Gentoo. Basically, it needs a Gentoo maintainer >>>>>>> now. It would seem given the time span that no one wants to take >>>>>>> it.
Like others, I use it but didn't know it wasn't maintained anymore. >>>>>>> I hope someone will step up but if not, looks like we have to use >>>>>>> udev.
No, see the linked bugs. Someone has to actually make it compatible >>>>>> with the tags API which software is starting to use.
I think its only a matter of time.
https://github.com/eudev-project/eudev/pull/253
I'll apply the patch and test the builds if it helps, but I don't know >>>>> about testing the runtime functionality of libgudev.
and
ideally updating eudev for other stuff like this.
Of course. Just like any other PR to any other project :) What's your
point?
I don't know what you mean. My point is none of that has been happening.
I see, ok. I would agree with you, however, the author of that PR is a
member of eudev org, so I wouldn't say it's dead just yet.
Also note that the PR is a hack rather than a full implementation
of the functionality anyway, which may lead to runtime misbehaviour.
And that's fine for programs which don't make use of the new API.
and? Someone has to actually check that?
--
Best regards,
Alexey "DarthGandalf" Sokolov
Must eudev be 100% compatible with all the garbage that gets shoved
into udev to stay in ::gentoo? I don't see mdev being held to that
standard.
On 9/12/23, Alexey Sokolov <alexey+gentoo@asokolov.org> wrote:
11.09.2023 22:35, Sam James пишет:
Alexey Sokolov <alexey+gentoo@asokolov.org> writes:
11.09.2023 22:21, Sam James пишет:
orbea <orbea@riseup.net> writes:
On Mon, 11 Sep 2023 21:31:30 +0100Someone has to then bother reviewing it, merging it, releasing it,
Sam James <sam@gentoo.org> wrote:
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: >>>>>>>>>>Based on what? It has several commits this year and is currently >>>>>>>>> working on both of my systems. Is there something specific showing >>>>>>>>> why its not maintained?
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
.
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project was >>>>>>>> established on 2021-09-14 by Alpine, Devuan and Gentoo contributors >>>>>>>> (alphabetical order).
It seems to have a upstream that is active but no one is
maintaining it on Gentoo. Basically, it needs a Gentoo maintainer >>>>>>>> now. It would seem given the time span that no one wants to take >>>>>>>> it.
Like others, I use it but didn't know it wasn't maintained anymore. >>>>>>>> I hope someone will step up but if not, looks like we have to use >>>>>>>> udev.
No, see the linked bugs. Someone has to actually make it compatible >>>>>>> with the tags API which software is starting to use.
I think its only a matter of time.
https://github.com/eudev-project/eudev/pull/253
I'll apply the patch and test the builds if it helps, but I don't know >>>>>> about testing the runtime functionality of libgudev.
and
ideally updating eudev for other stuff like this.
Of course. Just like any other PR to any other project :) What's your
point?
I don't know what you mean. My point is none of that has been happening. >>>
I see, ok. I would agree with you, however, the author of that PR is a
member of eudev org, so I wouldn't say it's dead just yet.
Also note that the PR is a hack rather than a full implementation
of the functionality anyway, which may lead to runtime misbehaviour.
And that's fine for programs which don't make use of the new API.
and? Someone has to actually check that?
--
Best regards,
Alexey "DarthGandalf" Sokolov
On Mon, 11 Sep 2023 22:21:21 +0100
Sam James <sam@gentoo.org> wrote:
orbea <orbea@riseup.net> writes:
On Mon, 11 Sep 2023 21:31:30 +0100
Sam James <sam@gentoo.org> wrote:
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is currently
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
working on both of my systems. Is there something specific
showing why its not maintained?
.
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project
was established on 2021-09-14 by Alpine, Devuan and Gentoo
contributors (alphabetical order).
It seems to have a upstream that is active but no one is
maintaining it on Gentoo. Basically, it needs a Gentoo
maintainer now. It would seem given the time span that no one
wants to take it.Â
Like others, I use it but didn't know it wasn't maintained
anymore. I hope someone will step up but if not, looks like we
have to use udev.Â
No, see the linked bugs. Someone has to actually make it compatible
with the tags API which software is starting to use.
I think its only a matter of time.
https://github.com/eudev-project/eudev/pull/253
I'll apply the patch and test the builds if it helps, but I don't
know about testing the runtime functionality of libgudev.
Someone has to then bother reviewing it, merging it, releasing it, and
ideally updating eudev for other stuff like this.
Also note that the PR is a hack rather than a full implementation
of the functionality anyway, which may lead to runtime misbehaviour.
According to upstream it implement's systemd's fallback path as
explained in this comment.
https://github.com/eudev-project/eudev/issues/249#issuecomment-1675520914
However its fully possible to use Gentoo without requiring sticky-tags
so I don't really see the urgency that requires removing software that
has users that find it works for them. We even have the most recent
upstream release which came out only a few months ago.
Dale
:-)Â :-)Â
orbea <orbea@riseup.net> writes:
On Mon, 11 Sep 2023 22:21:21 +0100
Sam James <sam@gentoo.org> wrote:
orbea <orbea@riseup.net> writes:
On Mon, 11 Sep 2023 21:31:30 +0100
Sam James <sam@gentoo.org> wrote:
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
currently working on both of my systems. Is there something
specific showing why its not maintained?
.
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new
project was established on 2021-09-14 by Alpine, Devuan and
Gentoo contributors (alphabetical order).
It seems to have a upstream that is active but no one is
maintaining it on Gentoo. Basically, it needs a Gentoo
maintainer now. It would seem given the time span that no one
wants to take it.Â
Like others, I use it but didn't know it wasn't maintained
anymore. I hope someone will step up but if not, looks like we
have to use udev.Â
No, see the linked bugs. Someone has to actually make it
compatible with the tags API which software is starting to use.
I think its only a matter of time.
https://github.com/eudev-project/eudev/pull/253
I'll apply the patch and test the builds if it helps, but I don't
know about testing the runtime functionality of libgudev.
Someone has to then bother reviewing it, merging it, releasing it,
and ideally updating eudev for other stuff like this.
Also note that the PR is a hack rather than a full implementation
of the functionality anyway, which may lead to runtime
misbehaviour.
According to upstream it implement's systemd's fallback path as
explained in this comment.
https://github.com/eudev-project/eudev/issues/249#issuecomment-1675520914
That same comment goes on to say it's the "quick-n-dirty" fix and may
break applications.
However its fully possible to use Gentoo without requiring
sticky-tags so I don't really see the urgency that requires
removing software that has users that find it works for them. We
even have the most recent upstream release which came out only a
few months ago.
Dale
:-)Â :-)Â
"Eddie Chapman" <eddie@ehuk.net> writes:
Sam James wrote:That only adds a stub - which isn't guaranteed to work correctly.
It seems there is work still ongoing to that end:
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea:Based on what? It has several commits this year and is currently
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
working on both of my systems. Is there something specific showing
why its not maintained?
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project was
established on 2021-09-14 by Alpine, Devuan and Gentoo
contributors (alphabetical order).
It seems to have a upstream that is active but no one is
maintaining it on Gentoo. Basically, it needs a Gentoo maintainer
now. It would seem given the time span that no one wants to take
it.Â
Like others, I use it but didn't know it wasn't maintained
anymore. I hope someone will step up but if not, looks like we have
to use udev.Â
No, see the linked bugs. Someone has to actually make it compatible
with the tags API which software is starting to use.
https://github.com/eudev-project/eudev/issues/249
A quick look at the bug list in the original announcement today, they
appear to almost all be bugs for Gentoo maintainers to address rather
than upstream, and one or two it's questionable if they are actually
bugs.
I've improved the mask message.
I think it is a rather large stretch to claim that upstream is dead,
the evidence just doesn't show that.
So what's the situation with the current Gentoo maintainers? Have they
disappeared? I often see on here packages being offered up for grabs.
Why
hasn't there been a call to give others the opportunity to volunteer as
maintainers rather than going straight tolast riting the package? Or
has that happened and I've missed it, in which case I apologise.
There was a year ago or so and nothing really came out of it. But see
above wrt 'tags'.
orbea <orbea@riseup.net> writes:
On Mon, 11 Sep 2023 22:50:13 +0100
Sam James <sam@gentoo.org> wrote:
orbea <orbea@riseup.net> writes:
On Mon, 11 Sep 2023 22:21:21 +0100
Sam James <sam@gentoo.org> wrote:
orbea <orbea@riseup.net> writes:
On Mon, 11 Sep 2023 21:31:30 +0100
Sam James <sam@gentoo.org> wrote:
Dale <rdalek1967@gmail.com> writes:
orbea wrote:
On Mon, 11 Sep 2023 17:29:47 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
Am Montag, 11. September 2023, 17:22:43 CEST schriebBased on what? It has several commits this year and is
orbea:
Upstream is maintained still.No, it's not.
https://github.com/eudev-project/eudev
currently working on both of my systems. Is there
something specific showing why its not maintained?
.
On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new
project was established on 2021-09-14 by Alpine, Devuan and
Gentoo contributors (alphabetical order).
It seems to have a upstream that is active but no one is
maintaining it on Gentoo. Basically, it needs a Gentoo
maintainer now. It would seem given the time span that no
one wants to take it.Â
Like others, I use it but didn't know it wasn't maintained
anymore. I hope someone will step up but if not, looks
like we have to use udev.Â
No, see the linked bugs. Someone has to actually make it
compatible with the tags API which software is starting to
use.
I think its only a matter of time.
https://github.com/eudev-project/eudev/pull/253
I'll apply the patch and test the builds if it helps, but I
don't know about testing the runtime functionality of
libgudev.
Someone has to then bother reviewing it, merging it, releasing
it, and ideally updating eudev for other stuff like this.
Also note that the PR is a hack rather than a full
implementation of the functionality anyway, which may lead to
runtime misbehaviour.
According to upstream it implement's systemd's fallback path as
explained in this comment.
https://github.com/eudev-project/eudev/issues/249#issuecomment-1675520914
That same comment goes on to say it's the "quick-n-dirty" fix and
may break applications.
Slibtool also has no-op compatibility fixes that potentially could
cause issues too, I don't see this being a problem there. If eudev
was entirely broken or not being used I could understand why to
remove it, but rather this is removing software that mostly works
and is being used. With all due honesty is very disappointing to
see this, I started to use Gentoo because it offered choices.
"mostly works" is generally not a great thing we want to
endorse.
slibtool is also a complete rewrite of libtool rather than a fork
which is out of date and missing features that consumers start
to expect from development. We also, importantly, don't drag in
slibtool on user systems unless they explicitly request it
and it doesn't wrongly satisfy dependencies on libtool itself.
Someone being disappointed doesn't get work done.
However its fully possible to use Gentoo without requiring
sticky-tags so I don't really see the urgency that requires
removing software that has users that find it works for them. We
even have the most recent upstream release which came out only a
few months ago.
Dale
:-)Â :-)Â
Regardless the disappointment is a valid concern when Gentoo is willing
to pull the rug up from under users feet under erroneous claims of the project being dead.
Sorry for this being a bit of a ramble. I do feel for your situation,
but I don't want to see you fighting the wrong battle. Disclaimer:
this is just my outside observation having seen many a treecleaning frustration in the past. I don't speak for any authority in Gentoo
here.
"Eddie Chapman" <eddie@ehuk.net> writes:
So what's the situation with the current Gentoo maintainers? Have
they disappeared? I often see on here packages being offered up for
grabs. Why
hasn't there been a call to give others the opportunity to volunteer
as maintainers rather than going straight to last riting the package?
Or
has that happened and I've missed it, in which case I apologise.
There was a year ago or so and nothing really came out of it. But see
above wrt 'tags'.
A year is a long time, there might well now be people willing to take
over maintaining it that were not willing to 1 year ago, if that is what
is required.
They have a month to step up anyway, although that will involve
upstream activity too.
Sam James wrote:
"Eddie Chapman" <eddie@ehuk.net> writes:
So what's the situation with the current Gentoo maintainers? Have
they disappeared? I often see on here packages being offered up for
grabs. Why
hasn't there been a call to give others the opportunity to volunteer >>>>> as maintainers rather than going straight to last riting the package? >>>>> Or
has that happened and I've missed it, in which case I apologise.
There was a year ago or so and nothing really came out of it. But see
above wrt 'tags'.
A year is a long time, there might well now be people willing to take
over maintaining it that were not willing to 1 year ago, if that is what >>> is required.
They have a month to step up anyway, although that will involve
upstream activity too.
I see there was already a change in the tree yesterday that assumes sys-fs/eudev is going (commit d46677fd864b30315423c8364ca44db2de98e2a1, sys-fs/mdadm/mdadm-4.2-r2, amd64 stable keyworded). Has this actually been decided behind the scenes already? This starts to smell a little ugly
unless I've completely misunderstood something. I hope I'm wrong.
One thing I don't understand: the Gentoo project page for eudev lists 4 members including the lead, and FWICT they are mostly still active in
other areas of Gentoo (recent commits to the tree in other packages). The project lead is also an original author of eudev.
I find it hard to
believe that all 4 of these people have completely lost interest in eudev
in Gentoo. Have any of these 4 maintainers publicly said (anywhere) that
they are not interested in being maintainers anymore (which is fine if
that is the case)? We're not talking here about a lone maintainer of some peripheral package that's disappeared leaving an orphaned package.
On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman <eddie@ehuk.net> wrote:
in Gentoo. Have any of these 4 maintainers publicly said (anywhere) that
they are not interested in being maintainers anymore (which is fine if
that is the case)? We're not talking here about a lone maintainer of some >> peripheral package that's disappeared leaving an orphaned package.
It isn't like somebody is censoring the lists or waging commit wars on
the metadata.xml/mask file. If somebody was eager to maintain it I'm
sure they'd have spoken up.
I'm an outsider to Gentoo development (just a heavy user for over a decade >> both personally and professionally) so I might have missed something. I
just find it puzzling.
I'm not puzzled by what is going on, or by your email, because it
happens basically anytime a high-profile package is treecleaned. Yes,
Gentoo is about choice, but somebody has to actually do work to make
the choices viable. There are always more people interested in using software than maintaining it. The frustration is completely
understandable, but also kinda unavoidable.
Repo QA standards don't mean that it has to barely work for your
specific use case. The package has to deal with compatibility issues
with stuff you don't use as well, which is why maintaining a system
package can be hard work. It is usually less of an issue for more
ordinary applications, which tend to have fewer interactions. If it
is "good enough" for you as it is, then just move it to a private
overlay and keep using it. You probably would need to override a
virtual or two as well. Or publish your work somewhere others can use
it.
in Gentoo. Have any of these 4 maintainers publicly said (anywhere) that
they are not interested in being maintainers anymore (which is fine if
that is the case)? We're not talking here about a lone maintainer of some peripheral package that's disappeared leaving an orphaned package.
I'm an outsider to Gentoo development (just a heavy user for over a decade both personally and professionally) so I might have missed something. I
just find it puzzling.
On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman <eddie@ehuk.net> wrote:
in Gentoo. Have any of these 4 maintainers publicly said (anywhere)
that they are not interested in being maintainers anymore (which is fine
if that is the case)? We're not talking here about a lone maintainer of
some peripheral package that's disappeared leaving an orphaned package.
It isn't like somebody is censoring the lists or waging commit wars on
the metadata.xml/mask file. If somebody was eager to maintain it I'm sure they'd have spoken up.
I'm an outsider to Gentoo development (just a heavy user for over a
decade both personally and professionally) so I might have missed
something. I just find it puzzling.
I'm not puzzled by what is going on, or by your email, because it
happens basically anytime a high-profile package is treecleaned. Yes,
Gentoo is about choice, but somebody has to actually do work to make
the choices viable. There are always more people interested in using software than maintaining it. The frustration is completely
understandable, but also kinda unavoidable.
Repo QA standards don't mean that it has to barely work for your
specific use case. The package has to deal with compatibility issues with stuff you don't use as well, which is why maintaining a system package can
be hard work. It is usually less of an issue for more ordinary
applications, which tend to have fewer interactions. If it is "good
enough" for you as it is, then just move it to a private overlay and keep using it. You probably would need to override a virtual or two as well.
Or publish your work somewhere others can use
it.
--
Rich
Sam James wrote:
"Eddie Chapman" eddie@ehuk.net writes:
So what's the situation with the current Gentoo maintainers? Have they disappeared? I often see on here packages being offered up for grabs. Why
hasn't there been a call to give others the opportunity to volunteer as maintainers rather than going straight to last riting the package? Or
has that happened and I've missed it, in which case I apologise.
There was a year ago or so and nothing really came out of it. But see above wrt 'tags'.
A year is a long time, there might well now be people willing to take over maintaining it that were not willing to 1 year ago, if that is what is required.
They have a month to step up anyway, although that will involve
upstream activity too.
I see there was already a change in the tree yesterday that assumes sys-fs/eudev is going (commit d46677fd864b30315423c8364ca44db2de98e2a1, sys-fs/mdadm/mdadm-4.2-r2, amd64 stable keyworded). Has this actually been decided behind the scenes already? This starts to smell a little ugly
unless I've completely misunderstood something. I hope I'm wrong.
One thing I don't understand: the Gentoo project page for eudev lists 4 members including the lead, and FWICT they are mostly still active in
other areas of Gentoo (recent commits to the tree in other packages). The project lead is also an original author of eudev. I find it hard to
believe that all 4 of these people have completely lost interest in eudev
in Gentoo. Have any of these 4 maintainers publicly said (anywhere) that
they are not interested in being maintainers anymore (which is fine if
that is the case)? We're not talking here about a lone maintainer of some peripheral package that's disappeared leaving an orphaned package.
I'm an outsider to Gentoo development (just a heavy user for over a decade both personally and professionally) so I might have missed something. I
just find it puzzling.
Rich Freeman wrote:
On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman <eddie@ehuk.net> wrote:
in Gentoo. Have any of these 4 maintainers publicly said (anywhere)
that they are not interested in being maintainers anymore (which is fine >>> if that is the case)? We're not talking here about a lone maintainer of >>> some peripheral package that's disappeared leaving an orphaned package.
It isn't like somebody is censoring the lists or waging commit wars on
the metadata.xml/mask file. If somebody was eager to maintain it I'm sure >> they'd have spoken up.
I'm an outsider to Gentoo development (just a heavy user for over a
decade both personally and professionally) so I might have missed
something. I just find it puzzling.
I'm not puzzled by what is going on, or by your email, because it
happens basically anytime a high-profile package is treecleaned. Yes,
Gentoo is about choice, but somebody has to actually do work to make
the choices viable. There are always more people interested in using
software than maintaining it. The frustration is completely
understandable, but also kinda unavoidable.
It starts to bother me that so many people straight away assume that when someone questions things it's because they are a frustrated user who just wants everyone else to do the work for them. And the same old argument
keeps being repeated over and over again *as if they think that no one
gets it* apart from us devs. I've been a free & oss software user for over
20 years and I find it very patronising whenever it happens. The reality
is that are very few people in this community that don't understand the fundamentals of free software, that no one is being paid, no one is obligated, we are all volunteers, well then why don't you do it, etc, etc.
I've never asked or expected anyone to actually step up and do the work
and if you read my messages you will see that I've never even implied it.
Repo QA standards don't mean that it has to barely work for your
specific use case. The package has to deal with compatibility issues with >> stuff you don't use as well, which is why maintaining a system package can >> be hard work. It is usually less of an issue for more ordinary
applications, which tend to have fewer interactions. If it is "good
enough" for you as it is, then just move it to a private overlay and keep
using it. You probably would need to override a virtual or two as well.
Or publish your work somewhere others can use
it.
I see, so again I just don't get it do I? I'm just a user who is in their
own little world and all they care about is what works for them, and I
don't think or understand anything about the bigger picture.
--
Rich
------- Original Message -------
On Tuesday, September 12th, 2023 at 3:36 PM, Eddie Chapman
<eddie@ehuk.net> wrote:
Sam James wrote:
"Eddie Chapman" eddie@ehuk.net writes:
So what's the situation with the current Gentoo maintainers?
Have
they disappeared? I often see on here packages being offered up
for grabs. Why hasn't there been a call to give others the
opportunity to volunteer as maintainers rather than going
straight to last riting the package? Or
has that happened and I've missed it, in which case I apologise.
There was a year ago or so and nothing really came out of it. But
see above wrt 'tags'.
A year is a long time, there might well now be people willing to
take over maintaining it that were not willing to 1 year ago, if
that is what is required.
They have a month to step up anyway, although that will involve
upstream activity too.
I see there was already a change in the tree yesterday that assumes
sys-fs/eudev is going (commit d46677fd864b30315423c8364ca44db2de98e2a1,
sys-fs/mdadm/mdadm-4.2-r2, amd64 stable keyworded). Has this actually
been decided behind the scenes already? This starts to smell a little
ugly unless I've completely misunderstood something. I hope I'm wrong.
One thing I don't understand: the Gentoo project page for eudev lists 4
members including the lead, and FWICT they are mostly still active in
other areas of Gentoo (recent commits to the tree in other packages).
The
project lead is also an original author of eudev. I find it hard to
believe that all 4 of these people have completely lost interest in
eudev in Gentoo. Have any of these 4 maintainers publicly said
(anywhere) that
they are not interested in being maintainers anymore (which is fine if
that is the case)? We're not talking here about a lone maintainer of
some peripheral package that's disappeared leaving an orphaned package.
I'm an outsider to Gentoo development (just a heavy user for over a
decade both personally and professionally) so I might have missed
something. I just find it puzzling.
I don't understand why there is need to go off of *hints and clues*
whether its active development or whether the project maintainers want to maintain it or not. The project lead has explained the original reason for eudev being part of base and why that reason has passed. Issue decided 2 years ago.
https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.htm
l
If there were maintainers to suport it for 2 extra years, that's very
nice of them. Speculating, without them, after their decision to
last-rite and asking to support eudev indefinitely, without giving any insightful reason as to why, seems ... not a great way to motivate
someone to do something extra for me.
Martin
Rich Freeman <rich0@gentoo.org> writes:
On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman <eddie@ehuk.net>
wrote:
in Gentoo. Have any of these 4 maintainers publicly said
(anywhere) that they are not interested in being maintainers
anymore (which is fine if that is the case)? We're not talking
here about a lone maintainer of some peripheral package that's
disappeared leaving an orphaned package.
It isn't like somebody is censoring the lists or waging commit wars
on the metadata.xml/mask file. If somebody was eager to maintain
it I'm sure they'd have spoken up.
I'm an outsider to Gentoo development (just a heavy user for over
a decade both personally and professionally) so I might have
missed something. I just find it puzzling.
I'm not puzzled by what is going on, or by your email, because it
happens basically anytime a high-profile package is treecleaned.
Yes, Gentoo is about choice, but somebody has to actually do work
to make the choices viable. There are always more people
interested in using software than maintaining it. The frustration
is completely understandable, but also kinda unavoidable.
Repo QA standards don't mean that it has to barely work for your
specific use case. The package has to deal with compatibility
issues with stuff you don't use as well, which is why maintaining a
system package can be hard work. It is usually less of an issue
for more ordinary applications, which tend to have fewer
interactions. If it is "good enough" for you as it is, then just
move it to a private overlay and keep using it. You probably would
need to override a virtual or two as well. Or publish your work
somewhere others can use it.
Yes. We value having a coherent system with decent UX and we have
to choose what we can support. Users are free to override those
choices in local repositories - and if they want advice on the best
way to do so, they're free to ask.
martin-kokos wrote:
------- Original Message -------
On Tuesday, September 12th, 2023 at 3:36 PM, Eddie Chapman
<eddie@ehuk.net> wrote:
Sam James wrote:
"Eddie Chapman" eddie@ehuk.net writes:
So what's the situation with the current Gentoo maintainers?
Have
they disappeared? I often see on here packages being offered up
for grabs. Why hasn't there been a call to give others the
opportunity to volunteer as maintainers rather than going
straight to last riting the package? Or
has that happened and I've missed it, in which case I apologise.
There was a year ago or so and nothing really came out of it. But
see above wrt 'tags'.
A year is a long time, there might well now be people willing to
take over maintaining it that were not willing to 1 year ago, if
that is what is required.
They have a month to step up anyway, although that will involve
upstream activity too.
I see there was already a change in the tree yesterday that assumes
sys-fs/eudev is going (commit d46677fd864b30315423c8364ca44db2de98e2a1,
sys-fs/mdadm/mdadm-4.2-r2, amd64 stable keyworded). Has this actually
been decided behind the scenes already? This starts to smell a little
ugly unless I've completely misunderstood something. I hope I'm wrong.
One thing I don't understand: the Gentoo project page for eudev lists 4
members including the lead, and FWICT they are mostly still active in
other areas of Gentoo (recent commits to the tree in other packages).
The
project lead is also an original author of eudev. I find it hard to
believe that all 4 of these people have completely lost interest in
eudev in Gentoo. Have any of these 4 maintainers publicly said
(anywhere) that
they are not interested in being maintainers anymore (which is fine if
that is the case)? We're not talking here about a lone maintainer of
some peripheral package that's disappeared leaving an orphaned package.
I'm an outsider to Gentoo development (just a heavy user for over a
decade both personally and professionally) so I might have missed
something. I just find it puzzling.
I don't understand why there is need to go off of *hints and clues*
whether its active development or whether the project maintainers want to
maintain it or not. The project lead has explained the original reason for >> eudev being part of base and why that reason has passed. Issue decided 2
years ago.
https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.htm
l
If there were maintainers to suport it for 2 extra years, that's very
nice of them. Speculating, without them, after their decision to
last-rite and asking to support eudev indefinitely, without giving any
insightful reason as to why, seems ... not a great way to motivate
someone to do something extra for me.
Martin
Thank you Martin and Sam for pointing out to me the news item above from 2 years ago, which for some reason I missed originally, so I wasn't aware
this is how the people listed as current maintainers felt.
This seems like a crucial piece of information that was sadly omitted from the original last rite message.
Maybe there is a lesson here somewhere about communication and last riting
of core system packages.
All this makes me wonder, what really is the reason for this shitshow. Something tells me systemd and it's shims will never be without a
maintainer, regardless of how "popular" they are among gentoo folks.
All this seems like intentional crippling of systemd alternatives. I
don't use eudev, but I don't like seeing choice being taken away for
such paper-thin reasons.
The "reasons" listed for the removal are "dead upstream", which is
false, and open "bugs", most of which are at most differences in the
default behavior.
I use a static /dev. That won't just stop working after an update,
regardless of how much money changes hands.
What does eudev need to do and doesn't do? From discussion in various
places, I understand that it must set permissions for a devtmpfs and
maybe create some symlinks. Does it not do that?
I know that Lennart wants to do everything and do it poorly, but eudev doesn't have to do that too. What's the point of a for then?
Overlays were mentioned in this thread. If we remove everything from
::gentoo in favor of overlays, what is the point of ::gentoo then? Do
devs receive prizes based on how many useful packages they remove?
Don't answer that, we all already know the answer.
There is this quote from "the doctor" on the forums that sums up all
the insanity:
As for software depending on what /dev you use, maybe he hasn't been
paying >attention but there is no sane reason any userspace
application should care how >the entries in /dev are made. There is
also no sane reason to break your API >every few months when the
good idea fairy comes to call.
As for this:
Alexe Stefan <stefanalexe48@gmail.com> writes:
Must eudev be 100% compatible with all the garbage that gets shoved
into udev to stay in ::gentoo? I don't see mdev being held to that
standard.
Please don't top-post.
mdev is not a provider of virtual/libudev and doesn't pretend to be
via its pkgconfig file.
What if eudev has to pretend, not because of build or runtime
failures, but because of needless pesky pkgconfig checks? Should the
default eudev setup include virtual/libudev in package.provided? I
think it's better the way it is.
As for software depending on what /dev you use, maybe he hasn't been paying >attention but there is no sane reason any userspace application should care how >the entries in /dev are made. There is also no sane reason to break your API >every few monthswhen the good idea fairy comes to call.
Alexe Stefan <stefanalexe48@gmail.com> writes:
Must eudev be 100% compatible with all the garbage that gets shoved
into udev to stay in ::gentoo? I don't see mdev being held to that
standard.
Please don't top-post.
mdev is not a provider of virtual/libudev and doesn't pretend to be
via its pkgconfig file.
Yes I regularly do this if there is a piece of software not in the tree, I have a local repo full of stuff. But this argument doesn't hold as much weight when it comes to a package like this which is integrated in the
core of the system. People who really want to continue using it are going
to experience a lot of pain trying to maintain it for themselves out of
tree, much more so than they would normally. That's one reason why I think the decision deserves more scrutiny.
On Tue, 12 Sep 2023 15:17:00 +0100
Sam James <sam@gentoo.org> wrote:
Rich Freeman <rich0@gentoo.org> writes:
On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman <eddie@ehuk.net>
wrote:
in Gentoo. Have any of these 4 maintainers publicly said
(anywhere) that they are not interested in being maintainers
anymore (which is fine if that is the case)? We're not talking
here about a lone maintainer of some peripheral package that's
disappeared leaving an orphaned package.
It isn't like somebody is censoring the lists or waging commit wars
on the metadata.xml/mask file. If somebody was eager to maintain
it I'm sure they'd have spoken up.
I'm an outsider to Gentoo development (just a heavy user for over
a decade both personally and professionally) so I might have
missed something. I just find it puzzling.
I'm not puzzled by what is going on, or by your email, because it
happens basically anytime a high-profile package is treecleaned.
Yes, Gentoo is about choice, but somebody has to actually do work
to make the choices viable. There are always more people
interested in using software than maintaining it. The frustration
is completely understandable, but also kinda unavoidable.
Repo QA standards don't mean that it has to barely work for your
specific use case. The package has to deal with compatibility
issues with stuff you don't use as well, which is why maintaining a system package can be hard work. It is usually less of an issue
for more ordinary applications, which tend to have fewer
interactions. If it is "good enough" for you as it is, then just
move it to a private overlay and keep using it. You probably would
need to override a virtual or two as well. Or publish your work somewhere others can use it.
Yes. We value having a coherent system with decent UX and we have
to choose what we can support. Users are free to override those
choices in local repositories - and if they want advice on the best
way to do so, they're free to ask.
As evidenced by the ::libressl overlay where I am repeatedly
copy/pasting changes from ::gentoo that have nothing to do with
libressl this is not a very good solution. This is a huge amount of
redundant and pointless effort that would be better suited being
directly in the ::gentoo repo.
What would be required so this is not required for eudev too? At the
risk of repeating myself its working on my systems and I am willing to
look at bugs and put in effort into keeping it functional.
I don't think this is a matter of not having people willing to put
effort in, but that no one wants to let them have the chance.
On Tue, Sep 12, 2023 at 1:24 PM Alexe Stefan <stefanalexe48@gmail.com> wrote:
All this makes me wonder, what really is the reason for this shitshow.
Something tells me systemd and it's shims will never be without a
maintainer, regardless of how "popular" they are among gentoo folks.
All this seems like intentional crippling of systemd alternatives. I
don't use eudev, but I don't like seeing choice being taken away for
such paper-thin reasons.
The "reasons" listed for the removal are "dead upstream", which is
false, and open "bugs", most of which are at most differences in the
default behavior.
I use a static /dev. That won't just stop working after an update,
regardless of how much money changes hands.
What does eudev need to do and doesn't do? From discussion in various
places, I understand that it must set permissions for a devtmpfs and
maybe create some symlinks. Does it not do that?
I know that Lennart wants to do everything and do it poorly, but eudev
doesn't have to do that too. What's the point of a for then?
Overlays were mentioned in this thread. If we remove everything from
::gentoo in favor of overlays, what is the point of ::gentoo then? Do
devs receive prizes based on how many useful packages they remove?
Don't answer that, we all already know the answer.
There is this quote from "the doctor" on the forums that sums up all
the insanity:
As for software depending on what /dev you use, maybe he hasn't been
paying >attention but there is no sane reason any userspace application
should care how >the entries in /dev are made. There is also no sane
reason to break your API >every few months when the good idea fairy
comes to call.
As for this:
Alexe Stefan <stefanalexe48@gmail.com> writes:
Must eudev be 100% compatible with all the garbage that gets shoved
into udev to stay in ::gentoo? I don't see mdev being held to that
standard.
Please don't top-post.
mdev is not a provider of virtual/libudev and doesn't pretend to be
via its pkgconfig file.
What if eudev has to pretend, not because of build or runtime
failures, but because of needless pesky pkgconfig checks? Should the
default eudev setup include virtual/libudev in package.provided? I
think it's better the way it is.
Lots of bad faith in this post. This is bad and you should feel bad.
All this makes me wonder, what really is the reason for this shitshow. Something tells me systemd and it's shims will never be without amonths when the good idea fairy comes to call.
maintainer, regardless of how "popular" they are among gentoo folks.
All this seems like intentional crippling of systemd alternatives. I
don't use eudev, but I don't like seeing choice being taken away for
such paper-thin reasons.
The "reasons" listed for the removal are "dead upstream", which is
false, and open "bugs", most of which are at most differences in the
default behavior.
I use a static /dev. That won't just stop working after an update,
regardless of how much money changes hands.
What does eudev need to do and doesn't do? From discussion in various
places, I understand that it must set permissions for a devtmpfs and
maybe create some symlinks. Does it not do that?
I know that Lennart wants to do everything and do it poorly, but eudev doesn't have to do that too. What's the point of a for then?
Overlays were mentioned in this thread. If we remove everything from
::gentoo in favor of overlays, what is the point of ::gentoo then? Do
devs receive prizes based on how many useful packages they remove?
Don't answer that, we all already know the answer.
There is this quote from "the doctor" on the forums that sums up all
the insanity:
As for software depending on what /dev you use, maybe he hasn't been paying >attention but there is no sane reason any userspace application should care how >the entries in /dev are made. There is also no sane reason to break your API >every few
As for this:
Alexe Stefan <stefanalexe48@gmail.com> writes:
Must eudev be 100% compatible with all the garbage that gets shoved
into udev to stay in ::gentoo? I don't see mdev being held to that
standard.
Please don't top-post.
mdev is not a provider of virtual/libudev and doesn't pretend to be
via its pkgconfig file.
What if eudev has to pretend, not because of build or runtime
failures, but because of needless pesky pkgconfig checks? Should the
default eudev setup include virtual/libudev in package.provided? I
think it's better the way it is.
On Tue, 12 Sep 2023 20:23:49 +0300
Alexe Stefan <stefanalexe48@gmail.com> wrote:
All this makes me wonder, what really is the reason for this shitshow.
Something tells me systemd and it's shims will never be without a
maintainer, regardless of how "popular" they are among gentoo folks. All
this seems like intentional crippling of systemd alternatives. I don't
use eudev, but I don't like seeing choice being taken away for such
paper-thin reasons. The "reasons" listed for the removal are "dead
upstream", which is false, and open "bugs", most of which are at most
differences in the default behavior.
I see 9 issues listed for sys-fs/eudev on the Gentoo tracker.
I closed 1 as invalid.
https://bugs.gentoo.org/904741
And submitted an upstream PR for another.
https://bugs.gentoo.org/771705 https://github.com/eudev-project/eudev/pull/261
As for the rest...
Possibly invalid?
https://bugs.gentoo.org/667686 (Outdated?)
https://bugs.gentoo.org/711462
Possibly outdated?
https://bugs.gentoo.org/713106
And the last 4 need to further investigation.
https://bugs.gentoo.org/851255
https://bugs.gentoo.org/770358
https://bugs.gentoo.org/668880
https://bugs.gentoo.org/753134
Surprisingly I don't see an issue for sticky-tags.
I use a static /dev. That won't just stop working after an update,
regardless of how much money changes hands.
What does eudev need to do and doesn't do? From discussion in various
places, I understand that it must set permissions for a devtmpfs and
maybe create some symlinks. Does it not do that? I know that Lennart
wants to do everything and do it poorly, but eudev doesn't have to do
that too. What's the point of a for then?
Overlays were mentioned in this thread. If we remove everything from
::gentoo in favor of overlays, what is the point of ::gentoo then? Do
devs receive prizes based on how many useful packages they remove? Don't
answer that, we all already know the answer.
There is this quote from "the doctor" on the forums that sums up all
the insanity:
As for software depending on what /dev you use, maybe he hasn't been
paying >attention but there is no sane reason any userspace application
should care how >the entries in /dev are made. There is also no sane
reason to break your API >every few months when the good idea fairy
comes to call.
As for this:
Alexe Stefan <stefanalexe48@gmail.com> writes:
Must eudev be 100% compatible with all the garbage that gets shoved
into udev to stay in ::gentoo? I don't see mdev being held to that
standard.
Please don't top-post.
mdev is not a provider of virtual/libudev and doesn't pretend to be
via its pkgconfig file.
What if eudev has to pretend, not because of build or runtime
failures, but because of needless pesky pkgconfig checks? Should the
default eudev setup include virtual/libudev in package.provided? I think
it's better the way it is.
On Tue, Sep 12, 2023 at 11:35 AM orbea <orbea@riseup.net> wrote:
On Tue, 12 Sep 2023 15:17:00 +0100
Sam James <sam@gentoo.org> wrote:
Rich Freeman <rich0@gentoo.org> writes:
On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman <eddie@ehuk.net>
wrote:
in Gentoo. Have any of these 4 maintainers publicly said
(anywhere) that they are not interested in being maintainers
anymore (which is fine if that is the case)? We're not talking
here about a lone maintainer of some peripheral package that's
disappeared leaving an orphaned package.
It isn't like somebody is censoring the lists or waging commit
wars on the metadata.xml/mask file. If somebody was eager to
maintain it I'm sure they'd have spoken up.
I'm an outsider to Gentoo development (just a heavy user for
over a decade both personally and professionally) so I might
have missed something. I just find it puzzling.
I'm not puzzled by what is going on, or by your email, because
it happens basically anytime a high-profile package is
treecleaned. Yes, Gentoo is about choice, but somebody has to
actually do work to make the choices viable. There are always
more people interested in using software than maintaining it.
The frustration is completely understandable, but also kinda unavoidable.
Repo QA standards don't mean that it has to barely work for your specific use case. The package has to deal with compatibility
issues with stuff you don't use as well, which is why
maintaining a system package can be hard work. It is usually
less of an issue for more ordinary applications, which tend to
have fewer interactions. If it is "good enough" for you as it
is, then just move it to a private overlay and keep using it.
You probably would need to override a virtual or two as well.
Or publish your work somewhere others can use it.
Yes. We value having a coherent system with decent UX and we have
to choose what we can support. Users are free to override those
choices in local repositories - and if they want advice on the
best way to do so, they're free to ask.
As evidenced by the ::libressl overlay where I am repeatedly
copy/pasting changes from ::gentoo that have nothing to do with
libressl this is not a very good solution. This is a huge amount of redundant and pointless effort that would be better suited being
directly in the ::gentoo repo.
I think most people aren't going to be swayed by "it's really
inefficient for me to do $xyz outside of ::gentoo" where xyz is
something that they find useless.
What would be required so this is not required for eudev too? At the
risk of repeating myself its working on my systems and I am willing
to look at bugs and put in effort into keeping it functional.
I don't think this is a matter of not having people willing to put
effort in, but that no one wants to let them have the chance.
Conspiracy alert!
It's been more than 2 years since https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html
People have had plenty of time. More chances than were fair have been
given. Nothing has changed, except eudev has further diverged from
upstream udev.
<snip>I'm an outsider to Gentoo development (just a heavy user for over a
decade both personally and professionally) so I might have missed
something. I just find it puzzling.
I'm not puzzled by what is going on, or by your email, because it
happens basically anytime a high-profile package is treecleaned. Yes, Gentoo is about choice, but somebody has to actually do work to make
the choices viable. There are always more people interested in using software than maintaining it. The frustration is completely understandable, but also kinda unavoidable.
It starts to bother me that so many people straight away assume that when someone questions things it's because they are a frustrated user
<snip>I'm an outsider to Gentoo development (just a heavy user for over a
decade both personally and professionally) so I might have missed
something. I just find it puzzling.
I'm not puzzled by what is going on, or by your email, because it
happens basically anytime a high-profile package is treecleaned. Yes,
Gentoo is about choice, but somebody has to actually do work to make
the choices viable. There are always more people interested in
using software than maintaining it. The frustration is completely
understandable, but also kinda unavoidable.
It starts to bother me that so many people straight away assume that
when someone questions things it's because they are a frustrated user
The eudev experiment has failed.
* It was false labeling from the start.[*]
* It's barely alive and not keeping up with udev upstream.
* It's effectively unmaintained in Gentoo.
* You don't gain anything from using it instead of udev.
(Nobody does.)
So why should anyone put up the effort to package it?
[*] Take something out of the systemd tarball, reapply every commit,
make tiny changes so it looks different,
sell it to the anti-systemd crowd.
Sadly no profit, since open source...
--
Andreas K. Hüttel
dilfridge@gentoo.org Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
orbea wrote:
On Tue, 12 Sep 2023 20:23:49 +0300
Alexe Stefan <stefanalexe48@gmail.com> wrote:
All this makes me wonder, what really is the reason for this
shitshow. Something tells me systemd and it's shims will never be
without a maintainer, regardless of how "popular" they are among
gentoo folks. All this seems like intentional crippling of systemd
alternatives. I don't use eudev, but I don't like seeing choice
being taken away for such paper-thin reasons. The "reasons" listed
for the removal are "dead upstream", which is false, and open
"bugs", most of which are at most differences in the default
behavior.
I see 9 issues listed for sys-fs/eudev on the Gentoo tracker.
I closed 1 as invalid.
https://bugs.gentoo.org/904741
And submitted an upstream PR for another.
https://bugs.gentoo.org/771705 https://github.com/eudev-project/eudev/pull/261
As for the rest...
Possibly invalid?
https://bugs.gentoo.org/667686 (Outdated?)
https://bugs.gentoo.org/711462
Possibly outdated?
https://bugs.gentoo.org/713106
And the last 4 need to further investigation.
https://bugs.gentoo.org/851255
https://bugs.gentoo.org/770358
https://bugs.gentoo.org/668880
https://bugs.gentoo.org/753134
Surprisingly I don't see an issue for sticky-tags.
I use a static /dev. That won't just stop working after an update,
regardless of how much money changes hands.
What does eudev need to do and doesn't do? From discussion in
various places, I understand that it must set permissions for a
devtmpfs and maybe create some symlinks. Does it not do that? I
know that Lennart wants to do everything and do it poorly, but
eudev doesn't have to do that too. What's the point of a for then?
Overlays were mentioned in this thread. If we remove everything
from ::gentoo in favor of overlays, what is the point of ::gentoo
then? Do devs receive prizes based on how many useful packages
they remove? Don't answer that, we all already know the answer.
There is this quote from "the doctor" on the forums that sums up
all the insanity:
As for software depending on what /dev you use, maybe he hasn't
been paying >attention but there is no sane reason any userspace
application should care how >the entries in /dev are made. There
is also no sane reason to break your API >every few months when
the good idea fairy comes to call.
As for this:
Alexe Stefan <stefanalexe48@gmail.com> writes:
Must eudev be 100% compatible with all the garbage that gets
shoved into udev to stay in ::gentoo? I don't see mdev being
held to that standard.
Please don't top-post.
mdev is not a provider of virtual/libudev and doesn't pretend to
be via its pkgconfig file.
What if eudev has to pretend, not because of build or runtime
failures, but because of needless pesky pkgconfig checks? Should
the default eudev setup include virtual/libudev in
package.provided? I think it's better the way it is.
Number of open bugs on its own is really not a good argument for
removing a package. sys-fs/udev has about 15 open bugs currently so
go figure. But the
sticky-tags API issue, to be fair to those who argue for eudev
removal, is the main issue, rather than the open bugs.
But I want to ask: what are the obstacles to keeping eudev in tree but effectively only for non-desktop use cases? I would love to hear
specific reasons from those who are pro-removal why eudev can't exist
at least for the server use case.
Because the sticky-tags issue only really affects desktop users. And
if some important server package comes along in future and wants to
use a new udev API feature, then implementing individual features in
eudev is more of a realistic proposition than the continual burden of implementing everything.
I have many Gentoo server instances out there and I really can't see
any sensible reason why eudev can't continue being the udev provider
in those scenarios, and surely portage can easily handle marking
eudev as not compatible with desktop package installations. Then for
desktop users the choice is between eudev or a desktop. Granted it's
not ideal but it's better than no eudev at all in tree, and I'm sure
there are other similar situations in tree currently where the user
has to make a choice between one or the other thing.
Now I know the argument that might come back is "well sure, but who's
going to do the work needed to be able to make the choice possible?".
Well, let's see, maybe someone will volunteer, but I just want to know
first is there any insurmountable obstacle that makes that scenario
not even possible?
On Tue, 12 Sep 2023 14:51:34 -0400
Matt Turner <mattst88@gentoo.org> wrote:
Conspiracy alert!
It's been more than 2 years since
https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html >>
People have had plenty of time. More chances than were fair have been
given. Nothing has changed, except eudev has further diverged from
upstream udev.
Unfortunately this flew under the radar for a lot of people, when I
asked Sam about this on irc a while ago I was informed (As I
understood) that eudev was still going to be an option into the future
and as the ebuild was still getting updates I never considered this is
how the core Gentoo devs felt.
On Tue, 12 Sep 2023 14:51:34 -0400
Matt Turner <mattst88@gentoo.org> wrote:
On Tue, Sep 12, 2023 at 11:35 AM orbea <orbea@riseup.net> wrote:
On Tue, 12 Sep 2023 15:17:00 +0100
Sam James <sam@gentoo.org> wrote:
Rich Freeman <rich0@gentoo.org> writes:
On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman <eddie@ehuk.net> wrote:
in Gentoo. Have any of these 4 maintainers publicly said
(anywhere) that they are not interested in being maintainers
anymore (which is fine if that is the case)? We're not talking
here about a lone maintainer of some peripheral package that's
disappeared leaving an orphaned package.
It isn't like somebody is censoring the lists or waging commit
wars on the metadata.xml/mask file. If somebody was eager to maintain it I'm sure they'd have spoken up.
I'm an outsider to Gentoo development (just a heavy user for
over a decade both personally and professionally) so I might
have missed something. I just find it puzzling.
I'm not puzzled by what is going on, or by your email, because
it happens basically anytime a high-profile package is
treecleaned. Yes, Gentoo is about choice, but somebody has to actually do work to make the choices viable. There are always
more people interested in using software than maintaining it.
The frustration is completely understandable, but also kinda unavoidable.
Repo QA standards don't mean that it has to barely work for your specific use case. The package has to deal with compatibility
issues with stuff you don't use as well, which is why
maintaining a system package can be hard work. It is usually
less of an issue for more ordinary applications, which tend to
have fewer interactions. If it is "good enough" for you as it
is, then just move it to a private overlay and keep using it.
You probably would need to override a virtual or two as well.
Or publish your work somewhere others can use it.
Yes. We value having a coherent system with decent UX and we have
to choose what we can support. Users are free to override those
choices in local repositories - and if they want advice on the
best way to do so, they're free to ask.
As evidenced by the ::libressl overlay where I am repeatedly
copy/pasting changes from ::gentoo that have nothing to do with
libressl this is not a very good solution. This is a huge amount of redundant and pointless effort that would be better suited being
directly in the ::gentoo repo.
I think most people aren't going to be swayed by "it's really
inefficient for me to do $xyz outside of ::gentoo" where xyz is
something that they find useless.
It doesn't matter if it sways you or not, the reality is that your
argument amounts to forcing people to do a lot of extra redundant work solving problems that have already been solved out of spite.
The eudev experiment has failed.
* It was false labeling from the start.[*]
* It's barely alive and not keeping up with udev upstream.
Why does it have to? It is advertised as a fork after all.
* It's effectively unmaintained in Gentoo.
That could change. Isn't that why a last rite comes with 30 days notice?
* You don't gain anything from using it instead of udev.
(Nobody does.)
Is there only 1 tool for the job? Why do we have both the OpenIPMI and >ipmitool projects, both curl and wget, chrome and firefox. Wouldn't it be >better if we just choose one of each of those pairs and concentrate on it?
So why should anyone put up the effort to package it?
Same question for the above choices and plenty of other examples.
What's wrong with having an alternative purely for competition?
Why would you think that by having an alternative in tree it means that everyone else is then forced into doing work that they don't want to and
it will inconvenience everyone?
What if someone came along now and said
they were willing to "step up" and maintain eudev and they were suitably qualified? Is that really going to force everyone else to modify their
ways?
On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman <eddie@ehuk.net> wrote:
Why would you think that by having an alternative in tree it means that
everyone else is then forced into doing work that they don't want to and
it will inconvenience everyone?
Because it's already happened!
commit 6404b064d63d182da4a8a193533a188cdf832d41
Author: Mike Gilbert <floppym@gentoo.org>
Date: Sun Jul 30 14:07:47 2023 -0400
virtual/libudev: add eudev and sticky-tags USE flags
eudev lacks API support for the new libudev functions that
differentiate
between sticky and current tags on device events.
Add a USE flag so we can depend on the new API from libgudev.
commit 319b4ed88674af738bd3fd90e56dc06c88de15db
Author: Mike Gilbert <floppym@gentoo.org>
Date: Sun Jul 30 14:10:44 2023 -0400
dev-libs/libgudev: depend on virtual/libudev[sticky-tags]
And as a result we have had at least three bug reports from users
complaining that they cannot update:
https://bugs.gentoo.org/913702
https://bugs.gentoo.org/913900
https://bugs.gentoo.org/913954
What if someone came along now and said
they were willing to "step up" and maintain eudev and they were suitably
qualified? Is that really going to force everyone else to modify their
ways?
It doesn't matter what people say. It matters what they do. And so far
no one has done anything in more than two years to make eudev worth
keeping.
But the core of the issue for me is -- how is eudev even the slightest
bit better in any way than systemd-utils[udev]?
On 9/13/23, Matt Turner <mattst88@gentoo.org> wrote:
On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman <eddie@ehuk.net> wrote:
Why would you think that by having an alternative in tree it means that
everyone else is then forced into doing work that they don't want to and >> it will inconvenience everyone?
Because it's already happened!
commit 6404b064d63d182da4a8a193533a188cdf832d41
Author: Mike Gilbert <floppym@gentoo.org>
Date: Sun Jul 30 14:07:47 2023 -0400
virtual/libudev: add eudev and sticky-tags USE flags
eudev lacks API support for the new libudev functions that differentiate
between sticky and current tags on device events.
Add a USE flag so we can depend on the new API from libgudev.
commit 319b4ed88674af738bd3fd90e56dc06c88de15db
Author: Mike Gilbert <floppym@gentoo.org>
Date: Sun Jul 30 14:10:44 2023 -0400
dev-libs/libgudev: depend on virtual/libudev[sticky-tags]
And as a result we have had at least three bug reports from users complaining that they cannot update:
https://bugs.gentoo.org/913702
https://bugs.gentoo.org/913900
https://bugs.gentoo.org/913954
What if someone came along now and said
they were willing to "step up" and maintain eudev and they were suitably >> qualified? Is that really going to force everyone else to modify their
ways?
It doesn't matter what people say. It matters what they do. And so far
no one has done anything in more than two years to make eudev worth keeping.
But the core of the issue for me is -- how is eudev even the slightest
bit better in any way than systemd-utils[udev]?
Is it such a burden to make a couple of commits once in a while?
How many commits were made in the last year to accommodate eudev?
Regarding the bugs, what else did you expect when no news item was given?
On 12 September 2023 21:47:31 CEST, Eddie Chapman <eddie@ehuk.net> wrote:
Andreas K. Huettel wrote:
The eudev experiment has failed.
* It was false labeling from the start.[*]
* It's barely alive and not keeping up with udev upstream.
Why does it have to? It is advertised as a fork after all.
* It's effectively unmaintained in Gentoo.
That could change. Isn't that why a last rite comes with 30 days
notice?
* You don't gain anything from using it instead of udev.Is there only 1 tool for the job? Why do we have both the OpenIPMI and
(Nobody does.)
ipmitool projects, both curl and wget, chrome and firefox. Wouldn't it
be better if we just choose one of each of those pairs and concentrate
on it?
So why should anyone put up the effort to package it?
Same question for the above choices and plenty of other examples.
What's wrong with having an alternative purely for competition?
Having options is only valuable if the different options actually bring something to the table. Choice for the sake of choice is just a waste of
time and effort. Firefox is clearly different then Chrome, each comes
with its own advantages and disadvantages, and based on this a user can
make an educated choice. What I have not yet read in any message in this
long thread, is **why** one would want to use eudev, what are its
advantages? Why not use sys-apps/systemd-utils[udev]?
You are free to spend your time and effort on whatever you wish, maintain eudev as proxy or in some overlay, but don't expect others to put in
their time and effort if you can't convince them the extra choice has
value and is therefore worth their time and effort.
Best regards,
Andrew
On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman <eddie@ehuk.net> wrote:
Why would you think that by having an alternative in tree it means that
everyone else is then forced into doing work that they don't want to
and it will inconvenience everyone?
Because it's already happened!
commit 6404b064d63d182da4a8a193533a188cdf832d41 Author: Mike Gilbert <floppym@gentoo.org>
Date: Sun Jul 30 14:07:47 2023 -0400
virtual/libudev: add eudev and sticky-tags USE flags
eudev lacks API support for the new libudev functions that differentiate between sticky and current tags on device events.
Add a USE flag so we can depend on the new API from libgudev.
commit 319b4ed88674af738bd3fd90e56dc06c88de15db Author: Mike Gilbert <floppym@gentoo.org>
Date: Sun Jul 30 14:10:44 2023 -0400
dev-libs/libgudev: depend on virtual/libudev[sticky-tags]
And as a result we have had at least three bug reports from users
complaining that they cannot update:
https://bugs.gentoo.org/913702
https://bugs.gentoo.org/913900
https://bugs.gentoo.org/913954
What if someone came along now and said
they were willing to "step up" and maintain eudev and they were suitably
qualified? Is that really going to force everyone else to modify their
ways?
It doesn't matter what people say. It matters what they do. And so far
no one has done anything in more than two years to make eudev worth
keeping.
But the core of the issue for me is -- how is eudev even the slightest
bit better in any way than systemd-utils[udev]?
I use a static /dev. That won't just stop work ing after an update, regardless of how much money changes hands.
What does eudev need to do and doesn't do? From discussion in various
places, I understand that it must set permissions for a devtmpfs and
maybe create some symlinks. Does it not do that?
There is this quote from "the doctor" on the forums that sums up all
the insanity:
As for software depending on what /dev you use, maybe he hasn't been paying >attention but there is no sane reason any userspace application should care how
the entries in /dev are made. There is also no sane reason to break your API >every few months when the good idea fairy comes to call.
assist in #gentoo on IRC as well as having submitted my fair share of bugs (and suggested fixes for them).Matt Turner wrote:
On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman <eddie@ehuk.net> wrote:
Why would you think that by having an alternative in tree it means that >>> everyone else is then forced into doing work that they don't want to
and it will inconvenience everyone?
Because it's already happened!
commit 6404b064d63d182da4a8a193533a188cdf832d41 Author: Mike Gilbert
<floppym@gentoo.org>
Date: Sun Jul 30 14:07:47 2023 -0400
virtual/libudev: add eudev and sticky-tags USE flags
eudev lacks API support for the new libudev functions that differentiate >> between sticky and current tags on device events.
Add a USE flag so we can depend on the new API from libgudev.
commit 319b4ed88674af738bd3fd90e56dc06c88de15db Author: Mike Gilbert
<floppym@gentoo.org>
Date: Sun Jul 30 14:10:44 2023 -0400
dev-libs/libgudev: depend on virtual/libudev[sticky-tags]
And as a result we have had at least three bug reports from users
complaining that they cannot update:
https://bugs.gentoo.org/913702
https://bugs.gentoo.org/913900
https://bugs.gentoo.org/913954
If I'm not mistaken these 3 bug reports are all from users trying to run >their systems free of systemd, i.e. with eudev. So it is the eudev users, >not the udev (presumably the majority) ones who have been inconvenienced.
But I think I see your point that here eudev is causing problems for
Gentoo devs who are seeing perhaps an influx of users complaining because >of the problem created by eudev not keeping up with udev API changes.
However, perhaps a better approach might have been a news item informing >users of dev-libs/libgudev i.e. desktop users that using eudev with >dev-libs/libgudev is no longer going to be possible going forward (which
is out of control of Gentoo) and that they had a choice of either >uninstalling their desktop environment (if it depended on >dev-libs/libgudev) or switching to udev. Then people who just run servers >can continue using eudev if they wish, and there would be no need to
remove it completely from the tree. This is the approach I have argued
for earlier in this thread.
What if someone came along now and said
they were willing to "step up" and maintain eudev and they were suitably >>> qualified? Is that really going to force everyone else to modify their >>> ways?
It doesn't matter what people say. It matters what they do. And so far
no one has done anything in more than two years to make eudev worth
keeping.
Yes I agree that actions matter not words. However, maintainership does >have to start with at least some words such as "OK I will step up and take >care of it"
But the core of the issue for me is -- how is eudev even the slightest
bit better in any way than systemd-utils[udev]?
Ok granted, as of right now eudev has not added any value as it has simply >forked, made some small changes but essentially does the same job.
However, again you're missing the point, there is a very significant
number of users who for subjective/political/whatever non-technical
reasons want eudev instead of udev. These are valid reasons, and before
you try and argue they are not examine your own software choices and ask >yourself if you always choose something entirely on technical merit.
And, to be honest, eudev does not *have* to do anything different. If it >provides roughly the same functionality as udev (minus new APIs) then it >serves its purpose and is good enough for those users who use it. There
are many examples of alternatives of one software or another that provide >roughly the same functionality and yet we don't discard one of them simply >because it is not adding features that make it subjectively better than
the other one.
Also, I don't think it's fair to just write the project off because it has >just been existing, providing the same functionality. There have been bug >fixes and new releases, isn't that the minimum we expect? It is certainly >not abandoned and dead as it has been characterised here. Maybe it will >become a proper fork in future and add something that udev doesn't have, >who knows.
OK a quick qualifier for me as a respondent:
I hate systemd with a passion, a key reason I use Gentoo is openrc and I wholeheartedly am of the belief that Poettering is an arse and systemd becoming defacto/ubiquitous in Linux was a dark day. I have contributed to the gentoo repo and regularly
That said, eudev is no hill to die on. The way Gentoo splits out udev from systemd accomplishes the goal of not having systemd "managing" your system, which was the goal of eudev. Also the goal of eudev was to be a DROP IN REPLACEMENT for udev, this isno longer the case. The thrust of the complaints about the removal seems to be "but it's going to be HARD to maintain this in an overlay" which is kinda the point of why it's being binned from ::gentoo: no one wants to do that work for the Gentoo
"Works on my machine" is an argument to use an overlay, not keep it in ::gentoo where we've already seen 3 duplicate bug reports where it _doesn't_ work on their machine. The upstream "fixes" for libgudev are a stub at best and "quick and dirty" atworst, which is a direct quote from the discussion of how to support libgudev. The PR to fix the API change is 50% "TODO" comments with fallback calls, the other 50% being a version bump and header hack. Folks have posted some absolutely heinous
eudev is no longer viable as something that provides virtual/libudev, that is its entire reason for existence in the ::gentoo repo.say that at time of writing eudev is not delivering on its drop in promise however little WHAT it doesn't satisfy concerns YOU as a complainer. For ::gentoo the entire userbase has to be considered.
I've read every single post on this thread, the comparisons to Firefox vs Chrome are utterly ridiculous, both are regularly maintained upstream and both still provide Web Access as people expect AND both have active package maintainers. It is safe to
The Gentoo team deserve precisely zero of the crap they're getting for this decision. Either step up as a maintainer if it matters to you so much, or maintain your own overlay if you only care about the things that matter to you, which is a lesserundertaking of work than someone keeping it viable for ::gentoo as a whole where working behaviour MATTERS for packages that depend on virtual/libudev.
If it doesn't matter for you, overlay it, turn off sticky-tags and if you have things that depend on libgudev, mask versions that want sticky-tags and it's an exercise for the user when that's no longer possible. I assure you at some point it willbecome no longer possible.
To call back to my intro, eudev gives nothing that being able to pluck udev from systemd gives, which Gentoo is able to do with aplomb. No systemd for me, openrc forever, cold dead hands etc. If that changes then that's a different discussion,whether eudev gets forked and revived or a new udev fork happens. Until then I suggest a lot of folks need to unbunch some underwear and either (in order of preference): get over it and switch to openrc with systemd udev, overlay with relevant USE flags
--AND ANOTHER THING... https://lists.freedesktop.org/archives/systemd-devel/2020-November/045646.html <- this is not an insignificant functionality change, the tag changes
Ninpo, known idiot
Matt Turner wrote:
On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman <eddie@ehuk.net> wrote: >>
Why would you think that by having an alternative in tree it means that
everyone else is then forced into doing work that they don't want to
and it will inconvenience everyone?
Because it's already happened!
commit 6404b064d63d182da4a8a193533a188cdf832d41 Author: Mike Gilbert
<floppym@gentoo.org>
Date: Sun Jul 30 14:07:47 2023 -0400
virtual/libudev: add eudev and sticky-tags USE flags
eudev lacks API support for the new libudev functions that differentiate
between sticky and current tags on device events.
Add a USE flag so we can depend on the new API from libgudev.
commit 319b4ed88674af738bd3fd90e56dc06c88de15db Author: Mike Gilbert
<floppym@gentoo.org>
Date: Sun Jul 30 14:10:44 2023 -0400
dev-libs/libgudev: depend on virtual/libudev[sticky-tags]
And as a result we have had at least three bug reports from users
complaining that they cannot update:
https://bugs.gentoo.org/913702
https://bugs.gentoo.org/913900
https://bugs.gentoo.org/913954
If I'm not mistaken these 3 bug reports are all from users trying to run >their systems free of systemd, i.e. with eudev. So it is the eudev users,
not the udev (presumably the majority) ones who have been inconvenienced.
But I think I see your point that here eudev is causing problems for
Gentoo devs who are seeing perhaps an influx of users complaining because
of the problem created by eudev not keeping up with udev API changes.
However, perhaps a better approach might have been a news item informing >users of dev-libs/libgudev i.e. desktop users that using eudev with >dev-libs/libgudev is no longer going to be possible going forward (which
is out of control of Gentoo) and that they had a choice of either >uninstalling their desktop environment (if it depended on
dev-libs/libgudev) or switching to udev. Then people who just run servers >can continue using eudev if they wish, and there would be no need to
remove it completely from the tree. This is the approach I have argued
for earlier in this thread.
What if someone came along now and said
they were willing to "step up" and maintain eudev and they were suitably >>> qualified? Is that really going to force everyone else to modify their
ways?
It doesn't matter what people say. It matters what they do. And so far
no one has done anything in more than two years to make eudev worth
keeping.
Yes I agree that actions matter not words. However, maintainership does
have to start with at least some words such as "OK I will step up and take >care of it"
But the core of the issue for me is -- how is eudev even the slightest
bit better in any way than systemd-utils[udev]?
Ok granted, as of right now eudev has not added any value as it has simply >forked, made some small changes but essentially does the same job.
However, again you're missing the point, there is a very significant
number of users who for subjective/political/whatever non-technical
reasons want eudev instead of udev. These are valid reasons, and before
you try and argue they are not examine your own software choices and ask >yourself if you always choose something entirely on technical merit.
And, to be honest, eudev does not *have* to do anything different. If it >provides roughly the same functionality as udev (minus new APIs) then it >serves its purpose and is good enough for those users who use it. There
are many examples of alternatives of one software or another that provide >roughly the same functionality and yet we don't discard one of them simply >because it is not adding features that make it subjectively better than
the other one.
Also, I don't think it's fair to just write the project off because it has >just been existing, providing the same functionality. There have been bug >fixes and new releases, isn't that the minimum we expect? It is certainly >not abandoned and dead as it has been characterised here. Maybe it will >become a proper fork in future and add something that udev doesn't have,
who knows.
<br>To call back to my intro, eudev gives nothing that being able to pluck udev from systemd gives, which Gentoo is able to do with aplomb. No systemd for me, openrc forever, cold dead hands etc. If that changes then that's a differentdiscussion, whether eudev gets forked and revived or a new udev fork happens. Until then I suggest a lot of folks need to unbunch some underwear and either (in order of preference): get over it and switch to openrc with systemd udev,  overlay with
Ninpo, known idiot<br></div></div>
Andreas K. Huettel wrote:
The eudev experiment has failed.
* It was false labeling from the start.[*]
* It's barely alive and not keeping up with udev upstream.
Why does it have to? It is advertised as a fork after all.
* It's effectively unmaintained in Gentoo.
That could change. Isn't that why a last rite comes with 30 days notice?
* You don't gain anything from using it instead of udev.
(Nobody does.)
Is there only 1 tool for the job? Why do we have both the OpenIPMI and ipmitool projects, both curl and wget, chrome and firefox. Wouldn't it be better if we just choose one of each of those pairs and concentrate on it?
So why should anyone put up the effort to package it?
Same question for the above choices and plenty of other examples.
What's wrong with having an alternative purely for competition?
[*] Take something out of the systemd tarball, reapply every commit,
make tiny changes so it looks different,
That's basically how most forks start isn't it?
You really are on a slippery slope if you're going to insist that someone "ought" to use a certain software, that there is no advantage in using an alternative and therefore you shouldn't. Also, people choose alternatives
for entirely non-technical reasons which are valid. These might be
political, license, or they just like the author or community of one
project better than another. Microsoft Office is probably a better office suite technically and feature-wise than Libreoffice, yet many people use Libreoffice instead. That doesn't mean Libreoffice users are "just plain wrong". Why do we have so many Linux distributions if they all offer
largely the same set of software? Why use Ubuntu over Debian or vice
versa? What's the point of openrc? Which is better GCC or Clang/LLVM?
Ok granted, as of right now eudev has not added any value as it has simply forked, made some small changes but essentially does the same job.
However, again you're missing the point, there is a very significant
number of users who for subjective/political/whatever non-technical
reasons want eudev instead of udev. These are valid reasons, and before
you try and argue they are not examine your own software choices and ask yourself if you always choose something entirely on technical merit.
And, to be honest, eudev does not *have* to do anything different. If it provides roughly the same functionality as udev (minus new APIs) then it serves its purpose and is good enough for those users who use it. There
are many examples of alternatives of one software or another that provide roughly the same functionality and yet we don't discard one of them simply because it is not adding features that make it subjectively better than
the other one.
On 9/13/23, Matt Turner <mattst88@gentoo.org> wrote:
On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan <stefanalexe48@gmail.com>
wrote:
Is it such a burden to make a couple of commits once in a while?
I see no commits from your email address in gentoo.git, so that might
be a question for you.
I and plenty of others have their overlays. Should I try to get my
ebuilds into ::gentoo?
How many commits were made in the last year to accommodate eudev?
I'm not your monkey.
Regarding the bugs, what else did you expect when no news item was given? >>Right, we should have done something *else* to keep eudev going.
Welcome to my killfile.
Something I said in this thread struck a chord?
On 9/13/23 12:35 AM, Alexe Stefan wrote:
On 9/13/23, Matt Turner <mattst88@gentoo.org> wrote:
On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan <stefanalexe48@gmail.com> >>> wrote:
Is it such a burden to make a couple of commits once in a while?
I see no commits from your email address in gentoo.git, so that might
be a question for you.
I and plenty of others have their overlays. Should I try to get my
ebuilds into ::gentoo?
That seems to be rather missing the point. Why are you going out of your
way to make a distinction between:
- contributing ebuilds that would otherwise not be present in ::gentoo
at all
- helping fix issues in existing ebuilds that are part of ::gentoo and
need to be kept in good working order
Both are valid ways to demonstrate a commitment to collaboratively
improving the Gentoo project. The one you *didn't* mention is easier to
do, though, so I'd probably suggest trying that first.
How many commits were made in the last year to accommodate eudev?
I'm not your monkey.
Regarding the bugs, what else did you expect when no news item was
given?
Right, we should have done something *else* to keep eudev going.
Welcome to my killfile.
Something I said in this thread struck a chord?
I think it's a very fair assessment to make that this thread is quite
hostile to the Gentoo Developers as a whole, and hostile behavior
towards the Gentoo Developers does indeed strike a chord.
I am not completely sure why you find it important or desirable to
highlight the fact that you elicit strong negative emotions in others,
mind you. But I'm sure you have very good reasons for it.
--
Eli Schwartz
On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan <stefanalexe48@gmail.com> wrote:
On 9/13/23, Matt Turner <mattst88@gentoo.org> wrote:
On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman <eddie@ehuk.net> wrote:
Why would you think that by having an alternative in tree it means
that
everyone else is then forced into doing work that they don't want to
and
it will inconvenience everyone?
Because it's already happened!
commit 6404b064d63d182da4a8a193533a188cdf832d41
Author: Mike Gilbert <floppym@gentoo.org>
Date: Sun Jul 30 14:07:47 2023 -0400
virtual/libudev: add eudev and sticky-tags USE flags
eudev lacks API support for the new libudev functions that
differentiate
between sticky and current tags on device events.
Add a USE flag so we can depend on the new API from libgudev.
commit 319b4ed88674af738bd3fd90e56dc06c88de15db
Author: Mike Gilbert <floppym@gentoo.org>
Date: Sun Jul 30 14:10:44 2023 -0400
dev-libs/libgudev: depend on virtual/libudev[sticky-tags]
And as a result we have had at least three bug reports from users
complaining that they cannot update:
https://bugs.gentoo.org/913702
https://bugs.gentoo.org/913900
https://bugs.gentoo.org/913954
What if someone came along now and said
they were willing to "step up" and maintain eudev and they were
suitably
qualified? Is that really going to force everyone else to modify their
ways?
It doesn't matter what people say. It matters what they do. And so far
no one has done anything in more than two years to make eudev worth
keeping.
But the core of the issue for me is -- how is eudev even the slightest
bit better in any way than systemd-utils[udev]?
Is it such a burden to make a couple of commits once in a while?
I see no commits from your email address in gentoo.git, so that might
be a question for you.
How many commits were made in the last year to accommodate eudev?
I'm not your monkey.
Regarding the bugs, what else did you expect when no news item was given?
Right, we should have done something *else* to keep eudev going.
Welcome to my killfile.
On 9/13/23, Eli Schwartz <eschwartz93@gmail.com> wrote:
On 9/13/23 12:35 AM, Alexe Stefan wrote:
On 9/13/23, Matt Turner <mattst88@gentoo.org> wrote:
On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan <stefanalexe48@gmail.com> >>>> wrote:
Is it such a burden to make a couple of commits once in a while?
I see no commits from your email address in gentoo.git, so that might
be a question for you.
I and plenty of others have their overlays. Should I try to get my
ebuilds into ::gentoo?
That seems to be rather missing the point. Why are you going out of your
way to make a distinction between:
- contributing ebuilds that would otherwise not be present in ::gentoo
at all
- helping fix issues in existing ebuilds that are part of ::gentoo and
need to be kept in good working order
Both are valid ways to demonstrate a commitment to collaboratively
improving the Gentoo project. The one you *didn't* mention is easier to
do, though, so I'd probably suggest trying that first.
I do open bugs and threads about various issues regarding packages,
and propose solutions. Sometimes their gentoo maintainers agree,
sometimes they don't. What else should I do? I don't have commit
access.
How many commits were made in the last year to accommodate eudev?
I'm not your monkey.
Regarding the bugs, what else did you expect when no news item was
given?
Right, we should have done something *else* to keep eudev going.
Welcome to my killfile.
Something I said in this thread struck a chord?
I think it's a very fair assessment to make that this thread is quite
hostile to the Gentoo Developers as a whole, and hostile behavior
towards the Gentoo Developers does indeed strike a chord.
I am not completely sure why you find it important or desirable to
highlight the fact that you elicit strong negative emotions in others,
mind you. But I'm sure you have very good reasons for it.
--
Eli Schwartz
I don't think I said anything about you?
I do not like to see choice being taken away for no good reason,
especially in regards to such a contested topic.
intentional crippling of systemd alternatives
regardless of how much money changes hands
Do devs receive prizes based on how many useful packages they remove?
Don't answer that, we all already know the answer.
most of those bugs were listed in the mask comment just to
increase the number of open bugs.
Alexe Stefan wrote:
While my posts may be a little bit inflammatory, no one pointed out
where I'm wrong.
I don't hate gentoo, but I don't want choice to be taken away from users.
If we(the users) only respond to issues that individually impact us,
choice will be taken away from everyone eventually(unless it's the
"right" choice as agreed by Lennart & co). It is called "divide and
conquer".
I do not hate gentoo. I want to see it offer as much choice as
possible, not restrict it.
I had to bear with systemd for some time before going to gentoo. I
don't want that to happen again.
I'm a eudev user. I don't like systemd either. I'm actually having to
deal with it for the first time after installing Ubuntu for a NAS box on
a under powered rig with not a lot of memory. I can honestly say, I
don't like systemd from experience. I'm one who will likely have to
switch to udev even tho I don't care too. While I'm not excited about
it, given the lack of coders wanting to keep it alive, I'll just have to switch. I may be losing a choice but hey, at least I had one that other distros never had. Some distros switched with no alternative long ago.
If I, someone who hates change, can change, I'm not sure why you can't
accept that eudev just may have reached its end of life on Gentoo. I
missed the news item a year or so ago. I had no idea it was not being maintained on Gentoo. This sort of hit me all at once, most likely the
same as you. Unless someone steps up in the next week or so, I'll be switching. At the least, I'm grateful to have OpenRC. Don't get me
started on trying to figure out how to restart a service on Ubuntu. As
bad as all the compiling is, Gentoo is a walk in the park. Restart a service, /etc/init.d/<start typing and hit tab twice when you think you
are close>. Try that in Ubuntu. Forget a hair cut this month. I'm
doing good to have hair. :@ Let's see what happens and if eudev dies,
let's accept it and be grateful for the time we did have a choice, while
some kinks got worked out of systemd udev at least.
To the other devs reading this thread still. Thanks much from a 20 year
user of Gentoo. It was bumpy at first but it sure has come a
LOOOOOOOONG ways. I can't say enough about how much emerge has improved
and how dependencies are resolved with ease for us users. The work on
the emerge command and ebuilds has improved a LOT. I still wish the
error output was more friendly but hey, at least there is a whole lot
less of it. :-D
Let's deal with what is in front of us. Thanks again to the devs.
Dale
:-) :-)
I'm going back to my hole now. <me hides>
On 9/13/23 1:03 AM, Alexe Stefan wrote:
On 9/13/23, Eli Schwartz <eschwartz93@gmail.com> wrote:
On 9/13/23 12:35 AM, Alexe Stefan wrote:
On 9/13/23, Matt Turner <mattst88@gentoo.org> wrote:
On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan <stefanalexe48@gmail.com> >>>>> wrote:
Is it such a burden to make a couple of commits once in a while?
I see no commits from your email address in gentoo.git, so that might >>>>> be a question for you.
I and plenty of others have their overlays. Should I try to get my
ebuilds into ::gentoo?
That seems to be rather missing the point. Why are you going out of your >>> way to make a distinction between:
- contributing ebuilds that would otherwise not be present in ::gentoo
at all
- helping fix issues in existing ebuilds that are part of ::gentoo and
need to be kept in good working order
Both are valid ways to demonstrate a commitment to collaboratively
improving the Gentoo project. The one you *didn't* mention is easier to
do, though, so I'd probably suggest trying that first.
I do open bugs and threads about various issues regarding packages,
and propose solutions. Sometimes their gentoo maintainers agree,
sometimes they don't. What else should I do? I don't have commit
access.
I am not sure what you're saying here. If you don't have commit access,
how do you intend to get your ebuilds into ::gentoo? If you don't need
commit access to get your ebuilds into ::gentoo, then what's stopping
you from getting your patches against existing ebuilds into ::gentoo?
Given that you were originally responding to Matt's remark that you have
no commits in ::gentoo associated with your email address, I am merely pointing out that you are performing a bit of self-gatekeeping by interpreting this as "my ebuilds" rather than "my code contributions".
If you propose solutions, do you include a demonstration patch to apply against ::gentoo that implements your proposed solution? Because that
would make it very easy to have those solutions become associated with
you. :)
How many commits were made in the last year to accommodate eudev?
I'm not your monkey.
Regarding the bugs, what else did you expect when no news item was >>>>>> given?
Right, we should have done something *else* to keep eudev going.
Welcome to my killfile.
Something I said in this thread struck a chord?
I think it's a very fair assessment to make that this thread is quite
hostile to the Gentoo Developers as a whole, and hostile behavior
towards the Gentoo Developers does indeed strike a chord.
I am not completely sure why you find it important or desirable to
highlight the fact that you elicit strong negative emotions in others,
mind you. But I'm sure you have very good reasons for it.
--
Eli Schwartz
I don't think I said anything about you?
I do not like to see choice being taken away for no good reason,
especially in regards to such a contested topic.
And I don't like signing up to this mailing list in order to email in a
patch against ::gentoo to improve the speed of compilation for python libraries and make them more easily tested and debuggable, and getting
my inbox filled with a bunch of yelling, hateful people who go around insulting the hard work of the Gentoo Developers, complaining that they didn't put in even MORE hard work, and figuratively screaming to the
heavens about how it's a conspiracy to deny choice.
You, in particular, even admitted you don't use eudev! But you're still
more than happy to pontificate about how it's, I dunno, the most useful
thing since sliced bread, or so I assume from the absolute moaning and wailing and gnashing of teeth about its removal. And you call it a
contested topic! Contested by people who don't use it and are only
contesting it in order to stir up trouble!
And not content to stick with pontificating about how useful the philosophical concept of choice between two copies of the same code with different marketing names that you don't even use is, you have to
describe it as
intentional crippling of systemd alternatives
regardless of how much money changes hands
(???????)
Do devs receive prizes based on how many useful packages they remove?
Don't answer that, we all already know the answer.
(lmao)
most of those bugs were listed in the mask comment just to
increase the number of open bugs.
I start to wonder: given you appear to despise the Gentoo Project with
an almighty hatred, why do you use the darned thing anyway. It's a
conspiracy to torment you and deny you choice, the Developers are
getting secretly paid to remove packages that disagree with the New
World Order of systemd, blah blah blah. Clearly Gentoo just has it in
for you, so you'd better escape before it's too late.
Can you please just not do this?
--
Eli Schwartz
Andrew Ammerlaan wrote:
On 12 September 2023 21:47:31 CEST, Eddie Chapman <eddie@ehuk.net> wrote:
Andreas K. Huettel wrote:
<snip>
* You don't gain anything from using it instead of udev.Is there only 1 tool for the job? Why do we have both the OpenIPMI and
(Nobody does.)
ipmitool projects, both curl and wget, chrome and firefox. Wouldn't it
be better if we just choose one of each of those pairs and concentrate
on it?
So why should anyone put up the effort to package it?
Same question for the above choices and plenty of other examples.
What's wrong with having an alternative purely for competition?
Having options is only valuable if the different options actually bring
something to the table. Choice for the sake of choice is just a waste of
time and effort. Firefox is clearly different then Chrome, each comes
with its own advantages and disadvantages, and based on this a user can
make an educated choice. What I have not yet read in any message in this
long thread, is **why** one would want to use eudev, what are its
advantages? Why not use sys-apps/systemd-utils[udev]?
You really are on a slippery slope if you're going to insist that someone "ought" to use a certain software, that there is no advantage in using an alternative and therefore you shouldn't. Also, people choose alternatives
for entirely non-technical reasons which are valid. These might be
political, license, or they just like the author or community of one
project better than another. Microsoft Office is probably a better office suite technically and feature-wise than Libreoffice, yet many people use Libreoffice instead. That doesn't mean Libreoffice users are "just plain wrong". Why do we have so many Linux distributions if they all offer
largely the same set of software? Why use Ubuntu over Debian or vice
versa? What's the point of openrc? Which is better GCC or Clang/LLVM?
You are free to spend your time and effort on whatever you wish, maintain
eudev as proxy or in some overlay, but don't expect others to put in
their time and effort if you can't convince them the extra choice has
value and is therefore worth their time and effort.
Best regards,
Andrew
Why would you think that by having an alternative in tree it means that everyone else is then forced into doing work that they don't want to and
it will inconvenience everyone? What if someone came along now and said
they were willing to "step up" and maintain eudev and they were suitably qualified? Is that really going to force everyone else to modify their
ways?
And then another thing, how is it possible that so many people missed
the news item? They are displayed quite prominently I think, and emerge
will keep buggering you about it until it is marked as read. Just
wondering if there is something that can be improved here.
On 9/12/23 3:47 PM, Eddie Chapman wrote:
Andreas K. Huettel wrote:It provides libudev.pc; this means that it is either engaged in
The eudev experiment has failed.Why does it have to? It is advertised as a fork after all.
* It was false labeling from the start.[*]
* It's barely alive and not keeping up with udev upstream.
deceptive and malicious false advertising, or...
... it is intended to provide compatibility with udev.
Hint: it is intended to provide compatibility with udev.
But, it does so with an OLD version of udev. Other projects throughout
the Linux ecosystem may depend on libudev.pc to provide API services; they have the right to use the advertised API of libudev.pc (and depend on a suitable version of it), but eudev cannot fulfill this contract as used by projects which e.g. use the sticky-tags API.
Thus, eudev is failing its goal to be a compatible replacement, because
it is not keeping up with udev upstream.
* It's effectively unmaintained in Gentoo.
That could change. Isn't that why a last rite comes with 30 days
notice?
Your question is a fallacy. Why are you pretending that the person you
are replying to has claimed it isn't going to change? The person you are replying to is describing the current state of affairs that led to the
last rite.
Who are you arguing against?
* You don't gain anything from using it instead of udev.
(Nobody does.)
Is there only 1 tool for the job? Why do we have both the OpenIPMI and
ipmitool projects, both curl and wget, chrome and firefox. Wouldn't it
be better if we just choose one of each of those pairs and concentrate
on it?
This isn't a fallacy -- it has progressed onwards and is now a
mendacious, twisting attempt at deception.
For the benefit of other people reading this discussion -- Firefox and
Chrome are vastly different programs, providing vastly different tools,
that both share a fairly vague, general domain (open web pages). wget and curl, or openIPMI and ipmitool, are less extreme examples of this general concept: they are different tools taking different approaches to
perform a somewhat more specific task, with pros and cons of each
approach.
eudev does not provide distinct functionality, which leads us on to...
So why should anyone put up the effort to package it?
Same question for the above choices and plenty of other examples.
What's wrong with having an alternative purely for competition?
[*] Take something out of the systemd tarball, reapply every commit,
make tiny changes so it looks different,
That's basically how most forks start isn't it?
There are two problems with this statement. The first is that it's
wrong, that's not how most forks start. The second is that you used the
word "start", without perhaps realizing that starts usually come with an afterwards that is distinguished from the start by not being the start.
But let's discuss what it means to fork software. There's a few
different reasons why a software project might fork:
- the maintainers of the project lost (or never possessed) legal control
over the trademark to some corporate interest, and "fork" their own project to a new name due to abuse against users by said corporate interest, in
order to reform the community and carry on their operations as normal. Examples: Sun OpenOffice.org -> LibreOffice. In
non-software, Freenode becoming Libera.Chat
- a project dies because its sole maintainer(s) disappear and cannot be contacted or are unresponsive w.r.t. the project. The community forks, changes its name, and arranges a new development team to "carry on the
torch" in memory of the old project. Example: TrueCrypt -> VeraCrypt
- a project has some end-user functionality proposed, and rejected. The people who want that feature decide to make their own project, based on the first project but with all their favorite features instead of the first project's favorite features. They take the codebase and start making lots
of changes to implement end-user functionality which they enjoy, and and
the first project makes lots of changes that *they* enjoy. Rapidly, it becomes increasingly difficult to find changes from one that are relevant
to the other. Example: gnome vs. cinnamon desktop
- a project changes in ways that some users are unhappy about, and those users create a fork that's exactly the same as the first project, but "with
X removed", and which regularly syncs with the first project to
retrieve desired features while excluding undesired features.
The third case is what most people think of when they talk about forks.
eudev is the fourth case, as its stated goal is to be "a fork of systemd", with the motivation of "isolating udev from [...] systemd". eudev lacks mission independence, its driving goal is to accomplish the same aims as systemd-udev except modularizing it well enough that it is neutral
regarding the init system you are running as pid1. To this end, it exposes the udev API, udev files, udev soname, udev programs and manpages...
eudev is also *failing* to be a good example of the fourth case, because having achieved "with X removed" it went a bit into stasis.
There's a few other issues to unpack here, it just doesn't end:
On 9/12/23 5:23 PM, Eddie Chapman wrote:
You really are on a slippery slope if you're going to insist that
someone "ought" to use a certain software, that there is no advantage in
using an alternative and therefore you shouldn't. Also, people choose
alternatives for entirely non-technical reasons which are valid. These
might be political, license, or they just like the author or community
of one project better than another. Microsoft Office is probably a
better office suite technically and feature-wise than Libreoffice, yet
many people use Libreoffice instead. That doesn't mean Libreoffice users
are "just plain wrong". Why do we have so many Linux distributions if
they all offer largely the same set of software? Why use Ubuntu over
Debian or vice
versa? What's the point of openrc? Which is better GCC or Clang/LLVM?
I think it's very easy to throw around terms like "slippery slope"
without having any real backing to it. The original objection that "there
is no advantage" to an alternative was quite straightforward: the lack of advantage is because they are in fact the same codebase, except eudev is missing some commits. It is not "an alternative to udev", it is "an alternative git repo providing the same old udev". This makes a big, big difference. There's no technical reason to prefer eudev over systemd-utils[udev], they are the same technical codebase. There's no licensing reason, both use the same licensing. There... is a political
reason to choose eudev, and that political reason is "the word systemd
makes me mad, and I do not want to have a program on my system which has
the word systemd in it, please fork the software in order to remove the
word systemd so that I can use it".
This is definitely a non-technical reason. It is not a *valid*
non-technical reason.
Comparing this to Microsoft Office vs. LibreOffice is... not an honest attempt to engage in mailing list discussion. Among the many technical reasons to choose between the two, Microsoft Office is not open source and
it doesn't run on Linux, so you do not in fact have a choice to use
Microsoft Office at all.
Similarly, the differences between distros are vast, even the
differences between Debian and Ubuntu. If nothing else, they provide different software, in addition to some common software.
So are the differences between GCC and clang/LLVM, most pointedly when
you consider dialect differences: some programs will only compile with one, some only with the other.
Please. Explain to me what functionality only works with eudev. I
already know what functionality only works with systemd-utils[udev].
On 9/12/23 6:35 PM, Eddie Chapman wrote:
Ok granted, as of right now eudev has not added any value as it has
simply forked, made some small changes but essentially does the same
job. However, again you're missing the point, there is a very
significant number of users who for subjective/political/whatever
non-technical reasons want eudev instead of udev. These are valid
reasons, and before you try and argue they are not examine your own
software choices and ask yourself if you always choose something
entirely on technical merit.
Okay, so now we all (hopefully) actually agree that eudev is strictly a subset of systemd-utils[udev] rather than an overlap, but...
... you're still arguing "it doesn't matter"?
Why should *anyone* care about "a very significant number" (citation
needed) of users that have political reasons?
Why are political reasons to want the package atom called "eudev"
without the "systemd" word inside, a valid grounds for imposing additional work on volunteers that haven't asked for it?
I dispute your claim that "subjective/political/whatever non-technical reasons" are *valid* reasons. I challenge your challenge that I can only argue this after examining my own software choices: I don't choose my software based on whether the word name of a project I politically dislike appears in package atoms, therefore I am consistent and have the moral
right to argue against doing so in the specific eudev case.
I am not being two-faced and objecting to politically motivated shunning
of the systemd-utils[udev] package due to personal biases in favor of
systemd while engaging in my own politically motivated shunning.
We good?
And, to be honest, eudev does not *have* to do anything different. If
it provides roughly the same functionality as udev (minus new APIs) then
it serves its purpose and is good enough for those users who use it.
There
are many examples of alternatives of one software or another that
provide roughly the same functionality and yet we don't discard one of
them simply because it is not adding features that make it subjectively
better than the other one.
Considering the large number of bad comparisons going on in this thread,
I would like to highlight this "does not have to do anything different"
with yet another comparison.
I like ebooks and have frequently used the app-text/sigil program. It
does build with cmake however. I dislike cmake and don't want it on my system, because something something politics and trying to force Windows workflows on developers. So I would like to fork the software and add an autotools or meson build system for it, and call the new package app-text/esigil. I demand that the Gentoo developers package it, so I can
rid my system of the nasty "cmake" word. (If this proposal is successful I can extend it to other packages as well.)
Note that esigil provides no functionality that sigil doesn't provide.
It is older, because I have to manually cherry-pick commits and
disentangle the "cmake" word, and I don't cherry-pick every commit because not all of them are relevant to my use case (there are some components I
just dropped). Also sometimes it's hard to backport patches because I have
to rework them to still apply, so I don't necessarily bother.
However, it's totally valid software, choice is important and
alternatives make for a healthy ecosystem, so please keep "esigil"
available. There is a very significant number of users using it (sorry, I can't provide citations for this) and anyone who argues against the
package is obviously a Microsoft shill because why else would they
advocate for a *cmake* project?
--
Eli Schwart
It seems like the discussion got way off-topic.
To see where where at, I'll try to summarize what was said so far.
The claims are that eudev is unmaintained upstream, downstream and has
open bugs.
Upstream, last commit was 3 weeks ago.
Downstream, Orbea said he is willing to help maintain it. He is known
for his great work on libressl(thank you), so there should be no
problems here.
Most of those bugs are invalid, outdated or being worked upon.
Are there any other problems here?
It seems like the discussion got way off-topic.
To see where where at, I'll try to summarize what was said so far.
The claims are that eudev is unmaintained upstream, downstream and has
open bugs.
Upstream, last commit was 3 weeks ago.
Downstream, Orbea said he is willing to help maintain it. He is known
for his great work on libressl(thank you), so there should be no
problems here.
Most of those bugs are invalid, outdated or being worked upon.
Are there any other problems here?
On 12/09/2023 23:23, Eddie Chapman wrote:
Andrew Ammerlaan wrote:
On 12 September 2023 21:47:31 CEST, Eddie Chapman <eddie@ehuk.net>
wrote:
Andreas K. Huettel wrote:
<snip>
* You don't gain anything from using it instead of udev.Is there only 1 tool for the job? Why do we have both the OpenIPMI
(Nobody does.)
and ipmitool projects, both curl and wget, chrome and firefox.
Wouldn't it
be better if we just choose one of each of those pairs and
concentrate on it?
Same question for the above choices and plenty of other examples.
So why should anyone put up the effort to package it?
What's wrong with having an alternative purely for competition?
Having options is only valuable if the different options actually
bring something to the table. Choice for the sake of choice is just a
waste of time and effort. Firefox is clearly different then Chrome,
each comes with its own advantages and disadvantages, and based on
this a user can make an educated choice. What I have not yet read in
any message in this long thread, is **why** one would want to use
eudev, what are its advantages? Why not use
sys-apps/systemd-utils[udev]?
You really are on a slippery slope if you're going to insist that
someone "ought" to use a certain software, that there is no advantage in
using an alternative and therefore you shouldn't. Also, people choose
alternatives for entirely non-technical reasons which are valid. These
might be political, license, or they just like the author or community
of one project better than another. Microsoft Office is probably a
better office suite technically and feature-wise than Libreoffice, yet
many people use Libreoffice instead. That doesn't mean Libreoffice users
are "just plain wrong". Why do we have so many Linux distributions if
they all offer largely the same set of software? Why use Ubuntu over
Debian or vice
versa? What's the point of openrc? Which is better GCC or Clang/LLVM?
This is a misrepresentation of my point. I never said that any rationale
for choosing one piece of software over another must be purely technical. A license, political issue or whatever may be a legitimate advantage that
one option has over another. I'm simply stating that no one has explicitly provided any rational for choosing eudev over systemd-utils[udev].
From the lack of response to my original question I can only conclude
that the only reason to choose eudev over systemd-utils[udev] is because
the latter package has "systemd" in the name (the horror!). If that is
truly the case it would be a lot simpler to rename sys-apps/systemd-utils
to sys-apps/utilities-from-the-init-system-that-must-not-be-named, then to
continue to maintain eudev.
You are free to spend your time and effort on whatever you wish,Why would you think that by having an alternative in tree it means that
maintain eudev as proxy or in some overlay, but don't expect others to
put in their time and effort if you can't convince them the extra
choice has value and is therefore worth their time and effort.
Best regards,
Andrew
everyone else is then forced into doing work that they don't want to
and it will inconvenience everyone? What if someone came along now and
said they were willing to "step up" and maintain eudev and they were
suitably qualified? Is that really going to force everyone else to
modify their ways?
If someone were to step up and say they are willing to spend their time
and effort maintaining eudev and fixing the open issues then sure we can
keep it, I never said otherwise. However this package has been maintainer-needed for quite a long time now and no one has stepped up, at some point someone has to pull the plug.
My point (which again you misrepresented) is that if you can't provided
a solid reason for choosing eudev over systemd-utils[udev] you are going to have a very hard time convincing others to put in their time and effort maintaining it, no matter how loudly you complain on the mailing list. So either maintain it yourself in some overlay, or provide some solid and convincing argumentation in favor of eudev. And as I already pointed out above "choice for the sake of choice" is not a convincing argument.
And then another thing, how is it possible that so many people missed
the news item? They are displayed quite prominently I think, and emerge
will keep buggering you about it until it is marked as read. Just
wondering if there is something that can be improved here.
Best regards,
Andrew
If someone were to step up and say they are willing to spend their time<snip>
and effort maintaining eudev and fixing the open issues then sure we can
keep it, I never said otherwise. However this package has been maintainer-needed for quite a long time now and no one has stepped up, at some point someone has to pull the plug.
Andrew Ammerlaan wrote:
<snip>
If someone were to step up and say they are willing to spend their time<snip>
and effort maintaining eudev and fixing the open issues then sure we can keep it, I never said otherwise. However this package has been maintainer-needed for quite a long time now and no one has stepped up, at some point someone has to pull the plug.
I am willing to help with the maintenance of eudev and field bug reports, either by preferably assisting another or as sole maintainer if that ended
up being the requirement (hopefully not as FWICT there is already one
other person volunteered). I would have time enough to be fully commit to this from 1st October onwards.
My understanding is that in it's current form it cannot remain because it does not support the new API features expected by libgudev. If someone
were to object to keep it for that reason then I'd propose to keep it but marked as incompatible with <= whatever version of libgudev introduced new API support. In this worst case scenario anyone with eudev currently installed would then have a choice of either uninstalling eudev, or uninstalling libgudev and any desktop depending libgudev. Then at the
very least all server installations who wish to keep eudev could continue doing so, which I think is a much better outcome than all current eudev
users having the proverbial rug pulled from under them.
On Thu, 14 Sept 2023 at 15:17, Eddie Chapman <eddie@ehuk.net> wrote:
Andrew Ammerlaan wrote:
<snip>
If someone were to step up and say they are willing to spend their<snip>
time and effort maintaining eudev and fixing the open issues then sure
we can keep it, I never said otherwise. However this package has been
maintainer-needed for quite a long time now and no one has stepped
up, at some point someone has to pull the plug.
I am willing to help with the maintenance of eudev and field bug
reports, either by preferably assisting another or as sole maintainer if
that ended up being the requirement (hopefully not as FWICT there is
already one other person volunteered). I would have time enough to be
fully commit to this from 1st October onwards.
My understanding is that in it's current form it cannot remain because
it does not support the new API features expected by libgudev. If
someone were to object to keep it for that reason then I'd propose to
keep it but marked as incompatible with <= whatever version of libgudev
introduced new API support. In this worst case scenario anyone with
eudev currently installed would then have a choice of either
uninstalling eudev, or uninstalling libgudev and any desktop depending
libgudev. Then at the very least all server installations who wish to
keep eudev could continue doing so, which I think is a much better
outcome than all current eudev users having the proverbial rug pulled
from under them.
It's not really libgudev related, it just so happens that libgudev is the first thing that's cropped up as using new features added to
systemd[udev].
Additionally the current proposals to "provide" such support are just
stubs or fallback calls, introducing unpredictable/surprising behaviour
for anything calling that part of the udev API.
Which brings us back to the rationale of keeping a package in ::gentoo
that's identical in every way to some older outdated version of
systemd[udev] for the sole purpose of "it doesn't say systemd", now with added surprises.
A maintainer would need to be willing to uphold the "provides virtual/libudev, honest guv" as well as deliver on the promises it makes
when it tells pkgconf what version it is. Not doing so is a support and
user headache later when more things use the new tags interface and subtle
or even not so subtle bugs creep in, new bugs get opened on b.g.o as well
as the added burden on #gentoo IRC.
--
Ninpo
Alex Boag-Munroe wrote:
On Thu, 14 Sept 2023 at 15:17, Eddie Chapman <eddie@ehuk.net> wrote:
Andrew Ammerlaan wrote:
<snip>
If someone were to step up and say they are willing to spend their<snip>
time and effort maintaining eudev and fixing the open issues then sure >>> we can keep it, I never said otherwise. However this package has been
maintainer-needed for quite a long time now and no one has stepped
up, at some point someone has to pull the plug.
I am willing to help with the maintenance of eudev and field bug
reports, either by preferably assisting another or as sole maintainer if >> that ended up being the requirement (hopefully not as FWICT there is
already one other person volunteered). I would have time enough to be
fully commit to this from 1st October onwards.
My understanding is that in it's current form it cannot remain because
it does not support the new API features expected by libgudev. If
someone were to object to keep it for that reason then I'd propose to
keep it but marked as incompatible with <= whatever version of libgudev
introduced new API support. In this worst case scenario anyone with
eudev currently installed would then have a choice of either
uninstalling eudev, or uninstalling libgudev and any desktop depending
libgudev. Then at the very least all server installations who wish to
keep eudev could continue doing so, which I think is a much better
outcome than all current eudev users having the proverbial rug pulled
from under them.
It's not really libgudev related, it just so happens that libgudev is the first thing that's cropped up as using new features added to
systemd[udev].
Additionally the current proposals to "provide" such support are just
stubs or fallback calls, introducing unpredictable/surprising behaviour
for anything calling that part of the udev API.
Which brings us back to the rationale of keeping a package in ::gentoo that's identical in every way to some older outdated version of systemd[udev] for the sole purpose of "it doesn't say systemd", now with added surprises.
A maintainer would need to be willing to uphold the "provides virtual/libudev, honest guv" as well as deliver on the promises it makes when it tells pkgconf what version it is. Not doing so is a support and user headache later when more things use the new tags interface and subtle or even not so subtle bugs creep in, new bugs get opened on b.g.o as well as the added burden on #gentoo IRC.
--
Ninpo
Yes I've been following with interest the gh issue upstream detailing the stub efforts and am aware that this approach is highly undesirable to many for the reasons you mentioned.
However, I think the prospect of anything in the server arena using these
new API features is very slim indeed, and if individual cases arise it's
easy to prevent them being installed together with eudev in the eudev
ebuild, and if those cases happen to be key system packages well *then*
it's game over for eudev. With my proposal people installing eudev would
have to accept big caveats about it not being guaranteed to work with everything, there may be unknown bugs, etc. But the undisputable fact and reality is that right now eudev "works fine" with just about everything without any show stoppers.
I know this approach will not be liked by what I would consider purists (I know not everyone would agree with that characterisation and that's fine
it's purely my own opinion) who want to have an ideal world in the system
but as long as it is only the eudev users this will affect (as everyone
else who wants Gnome or whatever will simply not install eudev, which
won't even be possible for them) I dare say people who want eudev on their system will be more than happy to accept the caveats.
Obviously eudev and libgudev right now cannot co-exist. But it would be
good to know; is anyone aware of any other non-desktop packages currently
in tree which have shown any signs/prospect upstream of wanting use the
new udev APIs?
On Thu, 14 Sept 2023 at 16:30, Eddie Chapman <eddie@ehuk.net> wrote:
Have you looked at the open issues list on eudev github? It's nothing to
Alex Boag-Munroe wrote:
On Thu, 14 Sept 2023 at 15:17, Eddie Chapman <eddie@ehuk.net> wrote:
Andrew Ammerlaan wrote:
<snip>
If someone were to step up and say they are willing to spend<snip>
their time and effort maintaining eudev and fixing the open issues
then sure we can keep it, I never said otherwise. However this
package has been maintainer-needed for quite a long time now and
no one has stepped up, at some point someone has to pull the plug.
I am willing to help with the maintenance of eudev and field bug
reports, either by preferably assisting another or as sole
maintainer if that ended up being the requirement (hopefully not as
FWICT there is
already one other person volunteered). I would have time enough to
be fully commit to this from 1st October onwards.
My understanding is that in it's current form it cannot remain
because it does not support the new API features expected by
libgudev. If someone were to object to keep it for that reason then
I'd propose to
keep it but marked as incompatible with <= whatever version of
libgudev introduced new API support. In this worst case scenario
anyone with eudev currently installed would then have a choice of
either uninstalling eudev, or uninstalling libgudev and any desktop
depending libgudev. Then at the very least all server installations
who wish to keep eudev could continue doing so, which I think is a
much better outcome than all current eudev users having the
proverbial rug pulled from under them.
It's not really libgudev related, it just so happens that libgudev is
the first thing that's cropped up as using new features added to
systemd[udev].
Additionally the current proposals to "provide" such support are just
stubs or fallback calls, introducing unpredictable/surprising
behaviour for anything calling that part of the udev API.
Which brings us back to the rationale of keeping a package in
::gentoo
that's identical in every way to some older outdated version of
systemd[udev] for the sole purpose of "it doesn't say systemd", now
with added surprises.
A maintainer would need to be willing to uphold the "provides
virtual/libudev, honest guv" as well as deliver on the promises it
makes when it tells pkgconf what version it is. Not doing so is a
support and user headache later when more things use the new tags
interface and subtle or even not so subtle bugs creep in, new bugs get
opened on b.g.o as well as the added burden on #gentoo IRC.
--
Ninpo
Yes I've been following with interest the gh issue upstream detailing
the stub efforts and am aware that this approach is highly undesirable
to many for the reasons you mentioned.
However, I think the prospect of anything in the server arena using
these new API features is very slim indeed, and if individual cases
arise it's easy to prevent them being installed together with eudev in
the eudev ebuild, and if those cases happen to be key system packages
well *then* it's game over for eudev. With my proposal people installing
eudev would have to accept big caveats about it not being guaranteed to
work with everything, there may be unknown bugs, etc. But the
undisputable fact and reality is that right now eudev "works fine" with
just about everything without any show stoppers.
I know this approach will not be liked by what I would consider purists
(I
know not everyone would agree with that characterisation and that's fine
it's purely my own opinion) who want to have an ideal world in the
system but as long as it is only the eudev users this will affect (as
everyone else who wants Gnome or whatever will simply not install eudev,
which won't even be possible for them) I dare say people who want eudev
on their system will be more than happy to accept the caveats.
Obviously eudev and libgudev right now cannot co-exist. But it would be
good to know; is anyone aware of any other non-desktop packages
currently in tree which have shown any signs/prospect upstream of
wanting use the new udev APIs?
do with being a "purist", as time moves on eudev is degrading due to a
lack of effort in keeping up with systemd[udev] and not just with this
latest tag feature, it just happens to be the one that got focused on for this discussion because it's starting to impact users.
Maintaining a package/package repo for a user base can't be done on
emotions, feelings or vibes; technical considerations come into play and as has repeatedly been asked in this thread, other than "I hate systemd it's icky and smells, more like Lennart POOPering amirite" what are the
technical reasons for trying to keep eudev stuck together with duct tape
and string, today, as opposed to simply lifting systemd[udev] and using
that?
The tags are the latest issue, they're absolutely not the only one and there's plenty of historical things to fix to actually fill on the promise
of "provides virtual/libudev".
--
Ninpo
Of course whether the Gentoo community would deem me as a suitable
maintainer and be willing to accept me as such is another matter entirely.
A maintainer would need to be willing to uphold the "provides virtual/libudev, honest guv" as well as deliver on the promises it makes<snip>
when it tells pkgconf what version it is. Not doing so is a support and
user headache later when more things use the new tags interface and subtle
or even not so subtle bugs creep in, new bugs get opened on b.g.o as well
as the added burden on #gentoo IRC.
if people want to run the damn thing just let them be!
On Thu, Sep 14, 2023 at 10:17 AM Eddie Chapman <eddie@ehuk.net> wrote:
Of course whether the Gentoo community would deem me as a suitable
maintainer and be willing to accept me as such is another matter
entirely.
You don't need any permissions from us to go fix eudev upstream.
Please focus on that (if you want) and less on filling our inboxes.
Rich Freeman wrote:
Not aiming this at you personally but this argument has been made more
than once in this thread and I personally don't think it carries any
weight, because it can be levelled at anyone who raises an issue about anything. If you don't like it, then just go and roll your own. Of course
I know I (and anyone else) can do that. So then what's the point of discussing anything then? What's the point of having a big tree with
hundreds of packages? Why not have a very minimal tree instead and let everyone go and run multiple independent repos so we can all do what we
want? Then we wouldn't have any discussion about what to include and what not. In fact maybe that's not a bad idea.
On Thu, Sep 14, 2023 at 12:50 PM Eddie Chapman <eddie@ehuk.net> wrote:
if people want to run the damn thing just let them be!
If you keep using eudev, and you don't tell anybody about it, then
they won't even know. Nobody is keeping anybody from using eudev. They're just not actively doing work to keep it working with changes in the repo.
If you stop syncing the repo, or fix those issues
yourself, or just avoid the use-cases that have issues, then you can use eudev forever.
You could even publish an overlay and accept contributions from others
who want to use eudev, so as to share the effort required to do so. You
don't need anybody's permission to do so - all you need is a free git repo somewhere to sync from. Being source-based, Gentoo is probably one of the easiest/most-practical distros out there to fork system-level packages on.
If you don't like it, then just go and roll your own. Of course
I know I (and anyone else) can do that. So then what's the point of discussing anything then?
What's the point of having a big tree with
hundreds of packages? Why not have a very minimal tree instead and let everyone go and run multiple independent repos so we can all do what we
want?
On Thu, 14 Sept 2023 at 17:50, Eddie Chapman <eddie@ehuk.net> wrote:
<snipped rant about choice and being told what to do>
No one is telling anyone not to use it. The question has been asked "why use it"
to ascertain reasons for keeping it in ::gentoo. Something not being in ::gentoo isn't a decree to not use it, it's a statement that it's a
pain to keep maintained
in portage for an entire user base.
If it was simply ordering/bullying people into not using it, the
advice to form a repo or
talk to guru or simply keep it in your own overlay wouldn't have been
given.
There's a huge difference between "suitable for a niche use case" and "suitable
for the entire Gentoo user base should they wish to make use of it". The latter
is where eudev had deteriorated for some time, again this current libgudev issue
being the latest example rather than the only one.
--
Ninpo
Gentoo is about choice, and we should keep it that way.
So what is the problem with keeping the package in ::gentoo.
Not aiming this at you personally but this argument has been made more
than once in this thread and I personally don't think it carries any
weight, because it can be levelled at anyone who raises an issue about anything. If you don't like it, then just go and roll your own.
Of course I know I (and anyone else) can do that. So then what's the
point of discussing anything then?
What's the point of having a big tree with hundreds of packages? Why
not have a very minimal tree instead and let everyone go and run
multiple independent repos so we can all do what we want? Then we
wouldn't have any discussion about what to include and what not. In
fact maybe that's not a bad idea.
"Eddie Chapman" <eddie@ehuk.net> writes:
Not aiming this at you personally but this argument has been made
more than once in this thread and I personally don't think it
carries any weight, because it can be levelled at anyone who raises
an issue about anything. If you don't like it, then just go and
roll your own.
::gentoo is supposed to be a coherent set of packages provided by
Gentoo developers, with a reasonable scope. eudev no longer fits
into the 'coherent' part of that definition, and there are zero
advantages to it over systemd-utils[udev].
The _only_ difference between a sys-fs/eudev::eudev and
sys-fs/eudev::gentoo package that would exist if the former were to be
made into an overlay is that Gentoo developers would be responsible
for the latter. There are no Gentoo developers interested in being responsible for the latter (AFAIK), and there is no tangible benefit
to the latter for any Gentoo developer to latch onto.
Seeing as there is at least half a dozen people seemingly interested
in maintaining eudev, why not just form an overlay? This way, virtual/{,lib}udev doesn't get polluted with implementations which
don't fullfil the definition of a virtual provider in ::gentoo, nor
with use-flag hacks, but users which wish to use eudev still have
access to it, and upstream eudev gets half a dozen potential
contributors, which are needed, _badly_. At risk of repeating
myself, I'd like to point out again that the only viable approach for
eudev upstream to take is to re-fork systemd and find a viable way to
stay up-to-date, while fixing up incompatibilities with musl. I've
made proposals a few years ago and restated them in this thread.
Of course I know I (and anyone else) can do that. So then what's the
point of discussing anything then?
Just because an argument is widely applicable does not make it
invalid.
Note that this argument is seldom the first resort, since, as you
note, it's not overly productive. Indeed, it was not the first
resort here. sys-fs/eudev has long overstayed the original removal
plan.
What's the point of having a big tree with hundreds of packages? Why
not have a very minimal tree instead and let everyone go and run
multiple independent repos so we can all do what we want? Then we
wouldn't have any discussion about what to include and what not. In
fact maybe that's not a bad idea.
I'm not sure how to fit this within the context of the thread.
Have a lovely evening.
On Fri, 15 Sep 2023 01:19:22 +0200
Arsen Arsenović <arsen@gentoo.org> wrote:
"Eddie Chapman" <eddie@ehuk.net> writes:
Not aiming this at you personally but this argument has been made
more than once in this thread and I personally don't think it
carries any weight, because it can be levelled at anyone who raises
an issue about anything. If you don't like it, then just go and
roll your own.
::gentoo is supposed to be a coherent set of packages provided by
Gentoo developers, with a reasonable scope. eudev no longer fits
into the 'coherent' part of that definition, and there are zero
advantages to it over systemd-utils[udev].
The _only_ difference between a sys-fs/eudev::eudev and
sys-fs/eudev::gentoo package that would exist if the former were to be
made into an overlay is that Gentoo developers would be responsible
for the latter. There are no Gentoo developers interested in being
responsible for the latter (AFAIK), and there is no tangible benefit
to the latter for any Gentoo developer to latch onto.
Seeing as there is at least half a dozen people seemingly interested
in maintaining eudev, why not just form an overlay? This way,
virtual/{,lib}udev doesn't get polluted with implementations which
don't fullfil the definition of a virtual provider in ::gentoo, nor
with use-flag hacks, but users which wish to use eudev still have
access to it, and upstream eudev gets half a dozen potential
contributors, which are needed, _badly_. At risk of repeating
myself, I'd like to point out again that the only viable approach for
eudev upstream to take is to re-fork systemd and find a viable way to
stay up-to-date, while fixing up incompatibilities with musl. I've
made proposals a few years ago and restated them in this thread.
What incompatibilities with musl? I am using musl-1.2.4 with eudev and
there do not seem to be any issues in that regard.
I also don't see any musl specific issues reported upstream or for
Gentoo. Am I missing something?
Of course I know I (and anyone else) can do that. So then what's the
point of discussing anything then?
Just because an argument is widely applicable does not make it
invalid.
Note that this argument is seldom the first resort, since, as you
note, it's not overly productive. Indeed, it was not the first
resort here. sys-fs/eudev has long overstayed the original removal
plan.
What's the point of having a big tree with hundreds of packages? Why
not have a very minimal tree instead and let everyone go and run
multiple independent repos so we can all do what we want? Then we
wouldn't have any discussion about what to include and what not. In
fact maybe that's not a bad idea.
I'm not sure how to fit this within the context of the thread.
Have a lovely evening.
15.09.2023 16:10, orbea пишет:
On Fri, 15 Sep 2023 01:19:22 +0200
Arsen Arsenović <arsen@gentoo.org> wrote:
"Eddie Chapman" <eddie@ehuk.net> writes:
Not aiming this at you personally but this argument has been made
more than once in this thread and I personally don't think it
carries any weight, because it can be levelled at anyone who
raises an issue about anything. If you don't like it, then just
go and roll your own.
::gentoo is supposed to be a coherent set of packages provided by
Gentoo developers, with a reasonable scope. eudev no longer fits
into the 'coherent' part of that definition, and there are zero
advantages to it over systemd-utils[udev].
The _only_ difference between a sys-fs/eudev::eudev and
sys-fs/eudev::gentoo package that would exist if the former were
to be made into an overlay is that Gentoo developers would be
responsible for the latter. There are no Gentoo developers
interested in being responsible for the latter (AFAIK), and there
is no tangible benefit to the latter for any Gentoo developer to
latch onto.
Seeing as there is at least half a dozen people seemingly
interested in maintaining eudev, why not just form an overlay?
This way, virtual/{,lib}udev doesn't get polluted with
implementations which don't fullfil the definition of a virtual
provider in ::gentoo, nor with use-flag hacks, but users which
wish to use eudev still have access to it, and upstream eudev gets
half a dozen potential contributors, which are needed, _badly_.
At risk of repeating myself, I'd like to point out again that the
only viable approach for eudev upstream to take is to re-fork
systemd and find a viable way to stay up-to-date, while fixing up
incompatibilities with musl. I've made proposals a few years ago
and restated them in this thread.
What incompatibilities with musl? I am using musl-1.2.4 with eudev
and there do not seem to be any issues in that regard.
I also don't see any musl specific issues reported upstream or for
Gentoo. Am I missing something?
Arsen meant incompatibilities of systemd-udev, not of eudev [1]. No
idea what's the current state of udev upstream is though. Alpine uses
musl, that's one of reasons why they are interested in eudev.
[1] See https://gitweb.gentoo.org/proj/eudev.git/commit/?id=f559dc96f4105f605272defac9276ef9cb6f5dc6
Of course I know I (and anyone else) can do that. So then what's
the point of discussing anything then?
Just because an argument is widely applicable does not make it
invalid.
Note that this argument is seldom the first resort, since, as you
note, it's not overly productive. Indeed, it was not the first
resort here. sys-fs/eudev has long overstayed the original removal
plan.
What's the point of having a big tree with hundreds of packages?
Why not have a very minimal tree instead and let everyone go and
run multiple independent repos so we can all do what we want?
Then we wouldn't have any discussion about what to include and
what not. In fact maybe that's not a bad idea.
I'm not sure how to fit this within the context of the thread.
Have a lovely evening.
"Eddie Chapman" <eddie@ehuk.net> writes:
Not aiming this at you personally but this argument has been made
more than once in this thread and I personally don't think it
carries any weight, because it can be levelled at anyone who raises
an issue about anything. If you don't like it, then just go and
roll your own.
::gentoo is supposed to be a coherent set of packages provided by
Gentoo developers, with a reasonable scope. eudev no longer fits
into the 'coherent' part of that definition, and there are zero
advantages to it over systemd-utils[udev].
The _only_ difference between a sys-fs/eudev::eudev and
sys-fs/eudev::gentoo package that would exist if the former were to be
made into an overlay is that Gentoo developers would be responsible
for the latter. There are no Gentoo developers interested in being responsible for the latter (AFAIK), and there is no tangible benefit
to the latter for any Gentoo developer to latch onto.
Seeing as there is at least half a dozen people seemingly interested
in maintaining eudev, why not just form an overlay? This way, virtual/{,lib}udev doesn't get polluted with implementations which
don't fullfil the definition of a virtual provider in ::gentoo, nor
with use-flag hacks, but users which wish to use eudev still have
access to it, and upstream eudev gets half a dozen potential
contributors, which are needed, _badly_. At risk of repeating
myself, I'd like to point out again that the only viable approach for
eudev upstream to take is to re-fork systemd and find a viable way to
stay up-to-date, while fixing up incompatibilities with musl. I've
made proposals a few years ago and restated them in this thread.
Of course I know I (and anyone else) can do that. So then what's the
point of discussing anything then?
Just because an argument is widely applicable does not make it
invalid.
Note that this argument is seldom the first resort, since, as you
note, it's not overly productive. Indeed, it was not the first
resort here. sys-fs/eudev has long overstayed the original removal
plan.
What's the point of having a big tree with hundreds of packages? Why
not have a very minimal tree instead and let everyone go and run
multiple independent repos so we can all do what we want? Then we
wouldn't have any discussion about what to include and what not. In
fact maybe that's not a bad idea.
I'm not sure how to fit this within the context of the thread.
Have a lovely evening.
Arsen meant incompatibilities of systemd-udev, not of eudev [1]. No
idea what's the current state of udev upstream is though. Alpine uses
musl, that's one of reasons why they are interested in eudev.
Oh, thanks for clarifying my misunderstanding. After re-reading I don't
know if eudev needs to be reforked, ...
... missing functionality that downstreams are using can be added...
... and otherwise focus on cleaning up and improving the code
independently of systemd. For instance there is no reason that
LibreSSL should refork OpenSSL.
[1] See
https://gitweb.gentoo.org/proj/eudev.git/commit/?id=f559dc96f4105f605272defac9276ef9cb6f5dc6
Of course I know I (and anyone else) can do that. So then what's
the point of discussing anything then?
Just because an argument is widely applicable does not make it
invalid.
Note that this argument is seldom the first resort, since, as you
note, it's not overly productive. Indeed, it was not the first
resort here. sys-fs/eudev has long overstayed the original removal
plan.
What's the point of having a big tree with hundreds of packages?
Why not have a very minimal tree instead and let everyone go and
run multiple independent repos so we can all do what we want?
Then we wouldn't have any discussion about what to include and
what not. In fact maybe that's not a bad idea.
I'm not sure how to fit this within the context of the thread.
Have a lovely evening.
I just want to reiterate that the overlay suggestion is bad and the
LibreSSL overlay is a good example of why.
The result is most of the work is redoing things that ::gentoio has
already done by copying ebuild changes where actual changes for
LibreSSL itself or for packages not compatible with it is a vast
minority of the work.
With eudev besides maintaining the eudev ebuild itself I suspect other ebuilds the overlay would have to maintain separate copies of are:
virtual/libudev
virtual/udev (Why are there two of these?)
sys-kernel/genkernel (?)
sys-fs/udev-init-scripts
sys-fs/mdadm
net-wireless/bluez
sys-apps/systemd-utils
And possibly others I missed which have minor changes for eudev, its significantly less work for ::gentoo to keep eudev than for a ::eudev
overlay to exist.
Of course I know I (and anyone else) can do that. So then what's the
point of discussing anything then?
Just because an argument is widely applicable does not make it
invalid.
Note that this argument is seldom the first resort, since, as you
note, it's not overly productive. Indeed, it was not the first
resort here. sys-fs/eudev has long overstayed the original removal
plan.
What's the point of having a big tree with hundreds of packages? Why
not have a very minimal tree instead and let everyone go and run
multiple independent repos so we can all do what we want? Then we
wouldn't have any discussion about what to include and what not. In
fact maybe that's not a bad idea.
I'm not sure how to fit this within the context of the thread.
Have a lovely evening.
Andrew Ammerlaan wrote:
And then another thing, how is it possible that so many people missed
the news item? They are displayed quite prominently I think, and
emerge will keep buggering you about it until it is marked as read.
Just wondering if there is something that can be improved here.
Best regards,
Andrew
I'm pretty good at reading the news items. I seem to recall that you
see one only if it affects you, you have a package installed or
something. So, if it shows up, it is best to take notice. That said, I don't recall seeing the news item either. I can't imagine me missing it
but I also can't imagine me not taking action either. After all, (eu)dev
is a important package.Â
One thing is for sure, the name is rather obvious. The first word in
the title is eudev. I have yet to figure out how I missed it. Given
the number of people who did, could there have been a glitch and it
didn't show for some weird reason? Has someone who understands the code checked to see if there was some typo that made it not show for most
users?Â
I do think this is worth looking into. It just seems odd.Â
[[PGP Signed Part:Undecided]]
On Wed, Sep 13, 2023 at 03:10:51 -0500, Dale wrote:
Andrew Ammerlaan wrote:
And then another thing, how is it possible that so many people missed
the news item? They are displayed quite prominently I think, and
emerge will keep buggering you about it until it is marked as read.
Just wondering if there is something that can be improved here.
Best regards,
Andrew
I'm pretty good at reading the news items. I seem to recall that you
see one only if it affects you, you have a package installed or
something. So, if it shows up, it is best to take notice. That said, I >> don't recall seeing the news item either. I can't imagine me missing it
but I also can't imagine me not taking action either. After all, (eu)dev
is a important package.Â
One thing is for sure, the name is rather obvious. The first word in
the title is eudev. I have yet to figure out how I missed it. Given
the number of people who did, could there have been a glitch and it
didn't show for some weird reason? Has someone who understands the code
checked to see if there was some typo that made it not show for most
users?Â
I do think this is worth looking into. It just seems odd.Â
It's not impossible for a news item to have bugs.
Somewhat recently, when the hardened toolchain changes were being made,
a news item was sent out recommending an `-e @world`. I knew it was
coming because I saw the drafts of the news item here (as well as
discussion on irc), so I was surprised when I didn't see it on my
laptop on the day of. But I did see it on my work machine.
We managed to track it down to my work machine using the hardened
profile whereas my laptop is using the hardened/selinux profile, and
Portage didn't quite catch that as being relevant for both.
- Oskari
[[End of PGP Signed Part]]
On Fri, 15 Sep 2023 01:19:22 +0200
Arsen Arsenović <arsen@gentoo.org> wrote:
"Eddie Chapman" <eddie@ehuk.net> writes:
Not aiming this at you personally but this argument has been made
more than once in this thread and I personally don't think it
carries any weight, because it can be levelled at anyone who
raises
an issue about anything. If you don't like it, then just go and
roll your own.Â
::gentoo is supposed to be a coherent set of packages provided by
Gentoo developers, with a reasonable scope. eudev no longer fits
into the 'coherent' part of that definition, and there are zero
advantages to it over systemd-utils[udev].
The _only_ difference between a sys-fs/eudev::eudev and sys-fs/eudev::gentoo package that would exist if the former were to
be
made into an overlay is that Gentoo developers would be responsible
for the latter. There are no Gentoo developers interested in being responsible for the latter (AFAIK), and there is no tangible benefit
to the latter for any Gentoo developer to latch onto.
Seeing as there is at least half a dozen people seemingly interested
in maintaining eudev, why not just form an overlay? This way, virtual/{,lib}udev doesn't get polluted with implementations which
don't fullfil the definition of a virtual provider in ::gentoo, nor
with use-flag hacks, but users which wish to use eudev still have
access to it, and upstream eudev gets half a dozen potential
contributors, which are needed, _badly_. At risk of repeating
myself, I'd like to point out again that the only viable approach
for
eudev upstream to take is to re-fork systemd and find a viable way
to
stay up-to-date, while fixing up incompatibilities with musl. I've
made proposals a few years ago and restated them in this thread.
I just want to reiterate that the overlay suggestion is bad and the
LibreSSL overlay is a good example of why. The result is most of the
work is redoing things that ::gentoio has already done by copying
ebuild changes where actual changes for LibreSSL itself or for
packages
not compatible with it is a vast minority of the work.
On Fri, 2023-09-15 at 15:40 -0700, orbea wrote:
On Fri, 15 Sep 2023 01:19:22 +0200
Arsen Arsenović <arsen@gentoo.org> wrote:
"Eddie Chapman" <eddie@ehuk.net> writes:
Not aiming this at you personally but this argument has been made
more than once in this thread and I personally don't think it
carries any weight, because it can be levelled at anyone who
raises
an issue about anything. If you don't like it, then just go and
roll your own.
::gentoo is supposed to be a coherent set of packages provided by
Gentoo developers, with a reasonable scope. eudev no longer fits
into the 'coherent' part of that definition, and there are zero
advantages to it over systemd-utils[udev].
The _only_ difference between a sys-fs/eudev::eudev and
sys-fs/eudev::gentoo package that would exist if the former were to
be
made into an overlay is that Gentoo developers would be responsible
for the latter. There are no Gentoo developers interested in being
responsible for the latter (AFAIK), and there is no tangible benefit
to the latter for any Gentoo developer to latch onto.
Seeing as there is at least half a dozen people seemingly interested
in maintaining eudev, why not just form an overlay? This way,
virtual/{,lib}udev doesn't get polluted with implementations which
don't fullfil the definition of a virtual provider in ::gentoo, nor
with use-flag hacks, but users which wish to use eudev still have
access to it, and upstream eudev gets half a dozen potential
contributors, which are needed, _badly_. At risk of repeating
myself, I'd like to point out again that the only viable approach
for
eudev upstream to take is to re-fork systemd and find a viable way
to
stay up-to-date, while fixing up incompatibilities with musl. I've
made proposals a few years ago and restated them in this thread.
I just want to reiterate that the overlay suggestion is bad and the
LibreSSL overlay is a good example of why. The result is most of the
work is redoing things that ::gentoio has already done by copying
ebuild changes where actual changes for LibreSSL itself or for
packages
not compatible with it is a vast minority of the work.
Many people told you that ::libressl is a waste of time, and you've
proven to us that it is.
Yet another example of choice being restricted by gentoo.
However, there at least is a better reason for not keeping libressl in ::Gentoo, that reason being qt.
With eudev, there is even less reason to remove it from ::gentoo.
The only maintenance burden with eudev is a couple of commits here and
there, mostly in virtuals.
Alexe Stefan <stefanalexe48@gmail.com> writes:
Yet another example of choice being restricted by gentoo.
However, there at least is a better reason for not keeping libressl in
::Gentoo, that reason being qt.
... and the swathes of other packages that are not compatible with it... especially since openssl:3 exists. Please face reality.
With eudev, there is even less reason to remove it from ::gentoo.
The only maintenance burden with eudev is a couple of commits here and
there, mostly in virtuals.
There's at least two reasons to remove it (it's unmaintained, out of
date, and incompatible), and at most zero to keep it.
Fix upstream and the reasons for removal will be gone, and the (illusion
of) choice will be there again. Note that I refuse to accept the idea
that this is choice. The code is the same.
Have a lovely night.
--
Arsen Arsenović
Upstream, it's maintained.
Downstream, 2 people volunteered.
So it is maintained.
The incompatibilities are for some desktop specific situations, and
there is a pr upstream(hacky, but work in progress).
For servers, or minimal desktops(which is what I expect gentoo is
mostly used for), eudev is fine.
In the meanwhile, while the two downstream volunteers address that, an ::eudev overlay can be established. As I went over in another email I
posted to this thread, it should not be particularly difficult to
implement or maintain (nowhere close to LibreSSL, for instance, as eudev didn't diverge nearly as much as LibreSSL did, and since
virtual/{lib,}udev exist).
On 9/17/23, Arsen Arsenović <arsen@gentoo.org> wrote:
In the meanwhile, while the two downstream volunteers address that, an
::eudev overlay can be established. As I went over in another email I
posted to this thread, it should not be particularly difficult to
implement or maintain (nowhere close to LibreSSL, for instance, as eudev
didn't diverge nearly as much as LibreSSL did, and since
virtual/{lib,}udev exist).
It seems like we will have to do this.
Should we make a new overlay or use an existing one?
If we make a new overlay, where should we host it?
There is the without-systemd overlay on github. Should we use that?
If we make something new, I'd rather it be on something like codeberg.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 17:43:19 |
| Calls: | 9,487 |
| Calls today: | 6 |
| Files: | 13,617 |
| Messages: | 6,121,090 |