[gentoo-dev] Last rites: sys-fs/eudev

[gentoo-dev] Last rites: sys-fs/eudev

[Mike Gilbert]

# eudev will be removed on 2022-01-01.
# Please see the news item published on 2021-08-24 for more information.
sys-fs/eudev

Re: [gentoo-dev] Last rites: sys-fs/eudev

[Jaco Kroon]

Hi Mike, Sam

This is the last I saw on the ML regarding eudev - has there been a
change of strategy regarding eudev since?

I note that the default provider for the virtual is systemd-utils[udev],
followed by sys-fs/udev, sys-fs/eudev and finally sys-apps/systemd. 
This contradicts the wiki page which states that sys-fs/udev is the
default (https://wiki.gentoo.org/wiki/Udev).

Is there more comprehensive documentation around about this, and which
should be preferred when?

The commit to un-last-rite this is the only information I can find, and
I don't see major releases since.

commit e170e1bb4c9ac1f63267298aa8eaab0d8f03c5e4
Author: Sam James <sam@gentoo.org>
Date:   Mon Dec 20 23:13:58 2021 +0000

    profiles: unmask/un-last-rite eudev
    
    It's now being maintained by a new upstream. I still recommend users
    use sys-fs/udev as sys-fs/eudev has not been rebased on newer
    upstream (yet?) but this allows choice for people who feel
    strongly about this, I suppose.
    
    Boot-tested and e.g. udevadm seems to work correctly with new
    hwdb bits.
    
    Thanks-to: kurly
    Signed-off-by: Sam James <sam@gentoo.org>


Kind Regards,
Jaco

Re: [gentoo-dev] Last rites: sys-fs/eudev

[Arve Barsnes]

On Tue, 30 Aug 2022 at 11:52, Jaco Kroon <jaco@uls.co.za> wrote:
> I note that the default provider for the virtual is systemd-utils[udev],
> followed by sys-fs/udev, sys-fs/eudev and finally sys-apps/systemd.
> This contradicts the wiki page which states that sys-fs/udev is the
> default (https://wiki.gentoo.org/wiki/Udev).
>
> Is there more comprehensive documentation around about this, and which
> should be preferred when?

sys-fs/udev is also just a virtual now, which pulls in
systemd-utils[udev], so using either works exactly the same.

Regards,
Arve

Re: [gentoo-dev] Last rites: sys-fs/eudev

[Jaco Kroon]

Hi Arve,

On 2022/08/30 12:27, Arve Barsnes wrote:

> On Tue, 30 Aug 2022 at 11:52, Jaco Kroon <jaco@uls.co.za> wrote:
>> I note that the default provider for the virtual is systemd-utils[udev],
>> followed by sys-fs/udev, sys-fs/eudev and finally sys-apps/systemd.
>> This contradicts the wiki page which states that sys-fs/udev is the
>> default (https://wiki.gentoo.org/wiki/Udev).
>>
>> Is there more comprehensive documentation around about this, and which
>> should be preferred when?
> sys-fs/udev is also just a virtual now, which pulls in
> systemd-utils[udev], so using either works exactly the same.

Thanks, I missed that.  That does help to clear things up.

This leaves three implementations, systemd-utils[udev], eudev and systemd.

We don't use systemd so that eliminates that, can I safely assume that
systemd-utils[udev] is "extracted" from systemd and really the same
thing?  Ie, it's the udevd without the associated systemd environment? 
So really only two implementations.

eudev then is the wild horse in that it was forked from the days when
sys-fs/udev got incorporated into systemd, and have been following a
parallel but somewhat independent path?  It doesn't contain many of the
newer systemd-udev "features" and "lags behind"?

Which, assuming then my understanding is now improved (which I believe
it is), then the selection should be based as follows:

1.  If you're using systemd, use the embedded udevd.
2.  If you're using openrc, you should prefer sys-fs/udev aka
systemd-utils[udev] unless you have a specific reason to rather use eudev?

eudev has served me very well for very long, and avoided a fair number
of LVM related deadlock issues we experienced with sys-fs/udev at the
time.  We've been moving back, and I'm not convinced those have been
eliminated, but I could not yet prove any of the recent system deadlocks
we've seen relates to systemd-udev.

(The one deadlock we did manage to trap was without a doubt something
with the linux kernel IO scheduler, possibly related to raid6, however,
lvm is also involved in that path, which does involve udev.  Also the
system that most frequently runs into problems - only one with software
raid6, but it also by far makes the most aggressive use of lvm
snapshots.  Thus no definitive patterns.)

Being a creature of habit based on experience I am sceptical.  I am
contemplating throwing that one host back to eudev and seeing if that
"solves" the problem ... but how long is a piece of string.

Thanks for the information, I'll let the above simmer a good long while.

Kind Regards,
Jaco

[gentoo-dev] last rites: sys-fs/eudev

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

# 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

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

[orbea]

On Mon, 11 Sep 2023 17:14:21 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

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

Please don't, I use this still. Upstream is maintained still.

https://github.com/eudev-project/eudev

Re: [gentoo-dev] last rites: sys-fs/eudev

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

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.


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

[orbea]

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?

Re: [gentoo-dev] last rites: sys-fs/eudev

[martin-kokos]

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?

Re: [gentoo-dev] last rites: sys-fs/eudev

[orbea]

On Mon, 11 Sep 2023 17:25:44 +0000
martin-kokos <martin-kokos@protonmail.com> wrote:

> Here.
> 
> https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html
> 

Please correct me if I am wrong, but I do not see any info on the
upstream status of the project there.

Its currently used in Alpine Linux, has recent commits and recent
PRs with upstream involvement and is fully working on more than one
users' systems. Why can't it simply exist in the ::gentoo repo for now?
It doesn't have to be and is not the default.

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Dale]

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

:-)  :-) 

Re: [gentoo-dev] last rites: sys-fs/eudev

[Sam James]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[orbea]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Sam James]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexey Sokolov]

11.09.2023 22:21, Sam James пишет:
> 
> 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:
>>>>>>   
>>>>>>> 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 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.

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.

libgudev is an interesting case here because it just exposes the API as 
GObject, including to various scripting languages; it doesn't use it by 
itself, some other program might do it through libgudev

-- 
Best regards,
Alexey "DarthGandalf" Sokolov

Re: [gentoo-dev] last rites: sys-fs/eudev

[orbea]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[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 +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:
>>>>>>>   
>>>>>>>> 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 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.
>
> 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?

Re: [gentoo-dev] last rites: sys-fs/eudev

[Sam James]

"Eddie Chapman" <eddie@ehuk.net> writes:

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

That only adds a stub - which isn't guaranteed to work correctly.

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexey Sokolov]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Sam James]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Sam James]

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.

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[orbea]

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

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Sam James]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

Sam James wrote:
>
> "Eddie Chapman" <eddie@ehuk.net> writes:
>
>> 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:
>>>>>>
>>>>>>> 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 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
>>
> That only adds a stub - which isn't guaranteed to work correctly.

But what that boils down to in practise if it actually turns out to be
true: user's might have to make a choice between installing some
application that uses a new API call not supported by eudev, or installing
eudev. I believe portage can handle that just fine, it regularly tells me
that there is some package or another that cannot be installed at the same
time as some other package. I'm sure I could go and find plenty of other
packages in the tree that can be last rites as well, if the inclusion
criteria for any given package is that it works with every other package
in the tree.

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

Yes that is an improvement.

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

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Sam James]

"Eddie Chapman" <eddie@ehuk.net> writes:

> Sam James wrote:
>>
>> "Eddie Chapman" <eddie@ehuk.net> writes:
>>
>>> 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:
>>>>>>>
>>>>>>>> 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 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
>>>
>> That only adds a stub - which isn't guaranteed to work correctly.
>
> But what that boils down to in practise if it actually turns out to be
> true: user's might have to make a choice between installing some
> application that uses a new API call not supported by eudev, or installing
> eudev. I believe portage can handle that just fine, it regularly tells me
> that there is some package or another that cannot be installed at the same
> time as some other package. I'm sure I could go and find plenty of other
> packages in the tree that can be last rites as well, if the inclusion
> criteria for any given package is that it works with every other package
> in the tree.
>

Yes, and then users kept getting confused by it, like
https://bugs.gentoo.org/913702 and its duplicates.

I doubt you can find many other packages which claim to satisfy a
library's API but only do so partially, like in the case here w/
virtual/libudev + eudev.

>>> 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.
>
> Yes that is an improvement.
>
>>> 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'.
>
> 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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[orbea]

On Mon, 11 Sep 2023 23:17:09 +0100
Sam James <sam@gentoo.org> wrote:

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

You are not installing eudev on systems unless the user requests it as
well and both slibtool and eudev are drop in replacements for their
respective counterpart where not all functionality is supported. They
both mostly work, by this logic we better remove slibtool too...

> 
> Someone being disappointed doesn't get work done.

If there are bugs on my systems I am willing to figure them out and try
to fix them, but its currently working just fine there and I won't be
able to fix any future issues if Gentoo removes it first.

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.

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Rich Freeman]

On Mon, Sep 11, 2023 at 10:34 PM orbea <orbea@riseup.net> wrote:
>
> 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.
>

As a complete outsider, I think this conversation is focusing on the
wrong issue.

IMO the main reason it is getting treecleaned is the lack of a
maintainer.  Everything about this entire back-and-forth screams
lack-of-maintainer.

You're essentially arguing that the Gentoo devs are out of touch with
the real status of upstream.  To a point I'd agree - that's because
normally it is a maintainer who stays on top of that stuff.

This is a fairly critical system package for anybody who has it
installed.  You don't want something like that not getting attention
when it has a problem, whether upstream or packaging-related.

Blueness kinda summed it up in his original news item.  This isn't
something that can be handled by a drive-by commit or two, or a
loosely involved proxy-maintainer.  Somebody needs to really step up
and take ownership of eudev for it to be viable.  Even if upstream
were great I wouldn't want to be using a stale package that is barely
maintained.

What is really needed is somebody stepping up and saying I will
maintain this.  If they were a Gentoo dev then the mask would probably
be gone already (IMO never would have happened if they stepped up
before now).  If it were a proxy I don't want to speculate too much
but they'd probably need to have a good history with such things.

Without anybody saying "I will personally fix this stuff" I just don't
see the treecleaning process stopping.  Arguing about the state of
upstream isn't going to change much, and if there were a maintainer
they'd just be dealing with it.

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.

-- 
Rich

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alarig Le Lay]

On Tue 12 Sep 2023 05:18:51 GMT, Rich Freeman wrote:
> 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.

I agree about the wrong battle. For those who want to use it after the
treeclean, why don’t you add it to guru (or a personal overlay if it’s
not accepted)?

-- 
Alarig

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Sam James]

"Eddie Chapman" <eddie@ehuk.net> writes:

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

I think someone just didn't want to bother waiting to clean it up there
given it's unlikely anyone will bother taking it over. It's not exactly
something which can't be undone.

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

blueness being the same person who wrote the news item last year saying it's dead and
it no longer serves a purpose.

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

That happened really with the discussion w/ blueness et. al when it was
last-rited (or before it was last-rited) originally.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Rich Freeman]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Sam James]

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[martin-kokos]

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

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Sam James]

"Eddie Chapman" <eddie@ehuk.net> writes:

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

No, but other people in the thread have, and the expectation is others
will read it too. This is one of those topics where in particular we
get a lot of it.

Suggestions of "something smelly" then do imply some of the things
you're saying. We're used to conspiratorial suggestions with this topic too.

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

I wouldn't read that much into it. Rich is always verbose (and I mean
no insult there), he's just being explicit about the options.


>
>> --
>> Rich

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

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

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Sam James]

"Eddie Chapman" <eddie@ehuk.net> writes:

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

I've just pushed
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6d1669686c56dc7f05750d9b36db1c2f9001275a
which I think should help.

That's a fair point, thank you. It's also easy to forget that people
might have missed an item etc.

Re: [gentoo-dev] last rites: sys-fs/eudev

[orbea]

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[orbea]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Matt Turner]

On Tue, Sep 12, 2023 at 11:04 AM Eddie Chapman <eddie@ehuk.net> wrote:
> 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.

Yes, people who insist on using a piece of software that's basically
stagnant are going to have trouble trying to maintain it themselves.
You're right.

You're just missing that this is because of upstream eudev not
backporting anything anymore.

Take a look at

https://openhub.net/p/eudev

12 month summary
* 22 Commits - Down -97 (81%) from previous 12 months
* 5 Contributors - Down -5 (50%) from previous 12 months

There used to be backports from upstream udev like this:
https://github.com/eudev-project/eudev/commit/9d4010a3629ebc1d915b7f2d3e2d7be83d79b4f4

But it seems that no one does that anymore since blueness stopped.
blueness -- one of the original maintainers of eudev and the author of
the news item that says the reason for eudev's existence no longer
applies...

So tl;dr: we're sorry eudev is no longer viable. We kept it in
::gentoo for far longer than it should have been.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Matt Turner]

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Matt Turner]

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

On 9/12/23, Matt Turner <mattst88@gentoo.org> wrote:
> 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.
>
>

Say what you will, but tell me where I was wrong in my post.
The reasons listed for the last rites are "dead upstream", which is
false and those bugs. Orbea wrote more about those bugs, but it seems
like most of those bugs were listed in the mask comment just to
increase the number of open bugs.

Re: [gentoo-dev] last rites: sys-fs/eudev

[orbea]

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.

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

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

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?

Re: [gentoo-dev] last rites: sys-fs/eudev

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

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

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)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

[orbea]

On Tue, 12 Sep 2023 20:06:32 +0100
"Eddie Chapman" <eddie@ehuk.net> wrote:

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

Agreed, that does seem the most pressing issue as far as I can tell,
the followup would probably be the cross-compile issue I submitted an
upstream PR for.

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

Even with a desktop its not necessarily an issue for someone using a
minimal window manager. Everything I want works just fine on my eudev
gaming system including Steam.

The only thing in the ::gentoo repo that requires sticky-tags is
dev-libs/libgudev which I believe is mostly required by desktop
managers such as Gnome. It appears to be optional in even XFCE, but I
am not sure of the ramifications of disabling the system-info USE flag
in xfce-base/libxfce4ui.

Additionally the workaround PR proposed for the upstream eudev repo
would make libgudev happy while potentially working satisfactorily in
many cases? This would require testing I can't accomplish.

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

I think this is effectively accomplished here?

https://github.com/gentoo/gentoo/blob/1ba10d93746ee934fc5bd0a5089e87d897d77eee/virtual/libudev/libudev-251-r1.ebuild#L15

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

Andreas K. Huettel wrote:
>>>> 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>
>
>
> 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?

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eli Schwartz]

On 9/12/23 3:05 PM, orbea wrote:
> 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.

It sounds to me like the last-rite system has worked and achieved the 
desired goal then. It is no longer flying under the radar, and for 
people who use eudev and wish to see it be a supported option, a fire 
has been lit under them to get involved.

Do keep in mind that based on commit history the only person that cares 
about eudev at all for years now is Sam, and that's apparently out of 
mere obligation. He is not listed as an eudev project member or package 
maintainer, the actual eudev project should likely acknowledge reality 
and disband in order to more effectively communicate their intent.

None of this is or ever was sustainable -- do not expect people who 
don't use a thing, aren't willing to maintain a thing, but intercede out 
of obligation to be an effective maintainer or be willing to do so in 
perpetuity.

If I had to take a wild guess, "it is still going to be an option into 
the future" actually meant "we aren't ready to treeclean it yet, people 
still use it, so we're gonna see how low-effort it is to keep it limping 
along without any maintainers but also maybe someone would like to 
maintain it".

Sure enough, the total lack of gentoo maintainers for this package meant 
that once people who were engaging with ebuild updates *purely* out of a 
sense of obligation could no longer justify continuing to do so when the 
package wasn't compatible with its reverse dependencies, those people 
decided that it was time to step down.

It's great to see people who do care and actually use the software, step 
up in their place.


-- 
Eli Schwartz

Re: [gentoo-dev] last rites: sys-fs/eudev

[Andrew Ammerlaan]

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

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Matt Turner]

On Tue, Sep 12, 2023 at 4:25 PM orbea <orbea@riseup.net> wrote:
>
> 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 lack of awareness here is really something.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Dale]

Eli Schwartz wrote:
> On 9/12/23 3:05 PM, orbea wrote:
>> 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.
>
> It sounds to me like the last-rite system has worked and achieved the
> desired goal then. It is no longer flying under the radar, and for
> people who use eudev and wish to see it be a supported option, a fire
> has been lit under them to get involved.
>
> Do keep in mind that based on commit history the only person that
> cares about eudev at all for years now is Sam, and that's apparently
> out of mere obligation. He is not listed as an eudev project member or
> package maintainer, the actual eudev project should likely acknowledge
> reality and disband in order to more effectively communicate their
> intent.
>
> None of this is or ever was sustainable -- do not expect people who
> don't use a thing, aren't willing to maintain a thing, but intercede
> out of obligation to be an effective maintainer or be willing to do so
> in perpetuity.
>
> If I had to take a wild guess, "it is still going to be an option into
> the future" actually meant "we aren't ready to treeclean it yet,
> people still use it, so we're gonna see how low-effort it is to keep
> it limping along without any maintainers but also maybe someone would
> like to maintain it".
>
> Sure enough, the total lack of gentoo maintainers for this package
> meant that once people who were engaging with ebuild updates *purely*
> out of a sense of obligation could no longer justify continuing to do
> so when the package wasn't compatible with its reverse dependencies,
> those people decided that it was time to step down.
>
> It's great to see people who do care and actually use the software,
> step up in their place.
>
>


Picking fairly random message to reply too. 

I'm a regular user, for some 20 years now.  I'm also a eudev user at the
moment.  I'm also not a fan of systemd and friends.  It's why I started
using eudev long ago.  So, like eudev, not much on systemd stuff and
currently use eudev.  With that info shared, this is my take on this.

It seems that while eudev is alive upstream for other distros, no one
cares to maintain it on Gentoo anymore because it doesn't serve a
purpose other than avoiding systemd.  While I kinda like that purpose,
I'm not maintaining eudev either.  If no one steps up and pinky swears
to maintain eudev, it will and should be removed from the tree.  After
all, this is about 2 years past due it seems.  While I wish someone
would maintain eudev, I'm not going to jump up and down demanding or
even implying someone should do so.  It sounds like it was easier in the
past to maintain it but upcoming changes is going to make that more time
consuming and require more work.  It appears no one is yet willing to
take that effort on. 

In my opinion, this thread has raised the awareness of the eudev
situation long ago.  If no one steps up, then it is time to retire eudev
and all of us eudev lovers will just have to switch.  This is just the
way FOSS works sometimes.  I recall switching from udev to eudev.  It
was as simple as unmerge one, emerge the other.  I assume it will be
pretty simple and straight forward this time to do the reverse.  I did
see somewhere that one should check configs and make sure there is no
systemd/udev entries, in case it masks or prevents something from being
installed.  I already checked mine.

My vote, give it time.  If someone steps up, great.  If not, we just
have to switch to udev and move on.  Debating it even more is unlikely
to change anything and may even send some running away.  I just wish we
knew just how many people actually used eudev.  Based on this thread, I
know of 2.  I know one of them can't code.  That's me!!  ;-) 

My $0.02 worth. 

Dale

:-)  :-) 

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

Andrew Ammerlaan wrote:
>
> 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.
>>> (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?
>
> 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?

Re: [gentoo-dev] last rites: sys-fs/eudev

[Matt Turner]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

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?

Re: [gentoo-dev] last rites: sys-fs/eudev

[Matt Turner]

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[karl]

Alexe Stefan:
...
> I use a static /dev. That won't just stop work ing after an update,
> regardless of how much money changes hands.

Nice to se a fellow static /dev user.

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

From what I understand, it is all about usb devices which comes and
goes, automounting things, and thoose things which only have dynamic
minor numbers. If it weren't for that there wouldn't be a need for any
*dev process.

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

Ack.

Regards,
/Karl Hammar

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alex Boag-Munroe]

[-- Attachment #1: Type: text/plain, Size: 8000 bytes --]

>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 assist in #gentoo on IRC as well as having
submitted my fair share of bugs (and suggested fixes for them).

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 is no 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 userbase.

"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" at worst, 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 discussions and
proposals from the eudev github as "proof" it's being maintained
adequately. Stubs and "quick and dirty" fixes aren't things I find suitable
for such a fundamental functionality of my system and I say this as a
former eudev user.

eudev is no longer viable as something that provides virtual/libudev, that
is its entire reason for existence in the ::gentoo repo.

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

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 lesser undertaking 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 will become 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 self
maintenance, or volunteer to maintain properly the sys-fs/eudev package
which not only includes keeping up with upstream but also delivering on the
promise that it can fulfill virtual/libudev.

--
Ninpo, known idiot

[-- Attachment #2: Type: text/html, Size: 9135 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alex Boag-Munroe]

On Wed, 13 Sept 2023 at 02:23, Alex Boag-Munroe <ninpo@qap.la> wrote:
>
> >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 assist in #gentoo on IRC as well as having submitted my fair share of bugs (and suggested fixes for them).
>
> 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 is no 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 userbase.
>
> "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" at worst, 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 discussions and proposals from the eudev github as "proof" it's being maintained adequately. Stubs and "quick and dirty" fixes aren't things I find suitable for such a fundamental functionality of my system and I say this as a former eudev user.
>
> eudev is no longer viable as something that provides virtual/libudev, that is its entire reason for existence in the ::gentoo repo.
>
> 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 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.
>
> 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 lesser undertaking 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 will become 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 self maintenance, or volunteer to maintain properly the sys-fs/eudev package which not only includes keeping up with upstream but also delivering on the promise that it can fulfill virtual/libudev.
>
> --
> Ninpo, known idiot
AND ANOTHER THING...
https://lists.freedesktop.org/archives/systemd-devel/2020-November/045646.html
<- this is not an insignificant functionality change, the tag changes
are there, are significant, thus will be used and behaviour will
depend on those calls being correct.  Anyone still mad about last
rites being issued on eudev clearly don't grasp the broad implications
of half arsing compatibility for an entire user base and are just
annoyed _their_ own world view doesn't match reality.

Yes open source is about choices. Viable ones.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eli Schwartz]

On 9/12/23 3:47 PM, Eddie Chapman 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 provides libudev.pc; this means that it is either engaged in
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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

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

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?

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eli Schwartz]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eli Schwartz]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

On 9/13/23, Eli Schwartz <eschwartz93@gmail.com> wrote:
> 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. :)
>

I didn't. Maybe I'll do that from now on.
To make it clear, the only way for my contributions to make their way
into gentoo is if a dev agrees with them. I do post workarounds and
hacks in various places though, including various overlays.

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

Since you specifically listed this as your last point of my
"conspiracy theories", I suggest you read orbea's post again, pointing
out how valid some of the bugs are and how others are being worked
upon or are outdated.

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

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

[-- Attachment #1: Type: text/plain, Size: 119 bytes --]

To be clear, I don't say that devs shouldn't get paid. They should just be
honest about who pays them to make changes.

[-- Attachment #2: Type: text/html, Size: 149 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

[Dale]

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>

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

On 9/13/23, Dale <rdalek1967@gmail.com> wrote:
> 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>
>
>

I do deal with what is in front of us. Today it's eudev. Tomorrow will
be opentmpfiles or openrc.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Dale]

Alexe Stefan wrote:
> On 9/13/23, Dale <rdalek1967@gmail.com> wrote:
>> 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>
>>
>>
> I do deal with what is in front of us. Today it's eudev. Tomorrow will
> be opentmpfiles or openrc.
>
>

And if they are no longer maintained, then what?  Post a lot of replies
on a mailing list? 

The point is, right now no one is wanting to maintain eudev.  There are
a lot of packages that get removed for the exact same reason.  Some are
no longer useful to anyone, some just don't have anyone to maintain
regardless of whether anyone uses them or not.  Once they are no longer
maintained and things start to break, they get removed.  Only if someone
steps up to maintain a package, does that package get to live.  It's
been that way for many years.  The packages you gave as examples, will
likely have their day as well, one day.

I don't think any of your posts has changed that fact.  In all honestly,
if anyone was interested in stepping up and at least trying to maintain
eudev, they most likely aren't now.  After all, if they stop maintaining
eudev later for whatever reason, they have you to look forward too.  I'm
sure several devs have your messages sent straight to the trash.  One
posted as much.  You are not accomplishing anything, likely even hurting
yourself. 

I think I'm done here too. 

Dale

:-)  :-) 

Re: [gentoo-dev] last rites: sys-fs/eudev

[Andrew Ammerlaan]

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.
>>>> (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?
>>
>> 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, 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?
> 

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Dale]

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. 

Dale

:-)  :-) 

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arve Barsnes]

On Wed, 13 Sept 2023 at 09:55, Andrew Ammerlaan
<andrewammerlaan@gentoo.org> 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.

I think ultimately the news item is irrelevant to the situation at the
moment. Soon after the news item, someone else took over and created a
new upstream. The news item does not concern the new maintainers, the
package was then never removed, and the package from the new upstream
was added to ::gentoo. In my opinion it's no mystery that no one would
remember what it said.

Regards,
Arve

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

Eli Schwartz wrote:
> On 9/12/23 3:47 PM, Eddie Chapman 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 provides libudev.pc; this means that it is either engaged in
> 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

Dear Eli,

Putting completely aside for a moment the issues being debated in this
thread, I first need to address the tone of your response as a whole,
which is shocking to me.

These are some parts of your response I strongly take issue with:

"This isn't a fallacy -- it has progressed onwards and is now a
mendacious, twisting attempt at deception."

"it just doesn't end"

"I think it's very easy to throw around terms like "slippery slope"
without having any real backing to it."

"Comparing this to Microsoft Office vs. LibreOffice is... not an honest
attempt to engage in mailing list discussion."

I would like to politely ask you to stop using this type of language,
which is completely unacceptable, if you address me again. These are all
examples of ridiculing other people's arguments, and of statements which
are insulting, and in my view are all unacceptable in public debate. I
have deliberately avoided those things in my responses which have all
remained courteous to everyone I have addressed. You should be ashamed of
letting yourself stoop so low!

It's a pity as I would have loved to actually engage in a good discussion
with you on the points you've made about the issues in this thread, all of
which you've argued very well and intelligently, some of which I agree
with, but most I disagree strongly with. I would have gladly responded to
all of your points, but when you started being insulting I lost all
respect for you so I won't. However, I'd be happy to engage with you again
if you were to apologise, privately off-list if you prefer, for being so
discourteous and assured me you are going to be polite in your responses
going forwards. If you are not prepared to do that, no problem, you are
perfectly entitled to  post whatever you like in whatever way you see fit
but I don't consider it a serious attempt to debate and won't engage in it
further.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

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?

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alex Boag-Munroe]

On Wed, 13 Sept 2023 at 10:34, Alexe Stefan <stefanalexe48@gmail.com> wrote:
>
> 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?
>

Yes, the general dip in overall activity and quality of what's going
on with upstream eudev maintenance, their approach to the
libgudev/sticky tags API change that triggered this discussion being a
great example.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 3482 bytes --]


Alexe Stefan <stefanalexe48@gmail.com> writes:

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

Please, take into account the contents of said commits.

One of the more recent ones bumps the version in the .pc file while
/stubbing/ only one of the APIs versions up to and including that one
added.

I've originally advocated for keeping eudev, and have put in some effort
to restart the project by essentially reforking systemd 'today' (i.e. at
the time a few years ago).  Since then it has been effectively
demonstrated to me that there is no interest in doing that (which is,
mind you, the only viable path for remaining compatible.  Note that
competition here is perfectly useless, so staying compatible is the only
viable path for the existence of the project *at all*); as a result, I
began to lose motivation to continue, combined with being quite busy
that year, I ended up simply switching to systemd-utils[udev], which was
equivalent, except up-to-date, without ever finishing extracting/porting
the needed shared code.

The merge-base (which is a rough measure but it provides a time frame)
of eudev and systemd is from Nov 2012, since then, only 1.3k commits
were added to the eudev tree (as opposed to the systemd tree, where
57.5k commits were added, note that not all of those, or even many of
those, are udev-related, but many are shared code between udev and other
components).

On top of that, only 143 of those were added to the repository since
Gentoo stopped maintaining eudev.

I estimate ~800 commits were added to systemd's udev since the eudev
project got separated (and then eudev was already trailing long
behind!), without counting shared code, so it's clear that eudev is
failing to keep pace, let alone catch up

I agree that upstream is alive.  That's what life support is.

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

LibreSSL is an excellent example of a fork that is only useful if it
remains compatible failing to be useful because it fails to be
compatible.  Thank you for bringing it up, it is quite a good cautionary
tale.  (naturally, I also used that back in the day...)

> Most of those bugs are invalid, outdated or being worked upon.
>
> Are there any other problems here?

The approach of forking in the traditional sense is fundamentally flawed
here.

If you want to keep eudev alive, please, do us all a favor and give
upstream a hand at re-forking systemd, and finding a sustainable
approach for keeping the fork up-to-date.  I originally did this by
filtering down the systemd repository into the appropriate directory
structure, and then adding in a new build system and extracting the
shared code.  The filtered repository can then be used as a branch or
separate repository that's merged into the new build system (either as a
subtree or as the toplevel).  This should have kept most of the code
easy to update.

PS: I had decided to respond to ~5 emails in this thread, but I realized
that the answer to all of them would be exactly what I wrote here.  This
thread feels like a lot of repetition.

Have a lovely day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

Andrew Ammerlaan wrote:
> 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.
>>>>> (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?
>>>
>>> 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,
>>> 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?
>
> 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

Hi Andrew,

I just want to apologise if I made you feel I misrepresented your points.
I certainly didn't mean to do that, and I was quite puzzled to read your
message just now and hear you say that, and having re-read what you wrote
and then I, I'm not sure I understand how I misrepresented you. But anyway
it doesn't matter if I see it or not, I'm sorry and I'll try harder in
future to not do that.

I want to make one thing clear which is I have stressed throughout this
thread that I'm not asking, expecting, demanding anything of anyone. One
of the few things I agree with most people on is that if no one steps up
to maintain then yes it cannot remain in tree, that is obvious. But many
people seem to interpret my arguments as just trying to make as much noise
as possible in order to get eudev to stay, which saddens me as they are
certainly not.

I'm still not much in agreement with you despite your further arguments
but I don't see any point in debating anymore. It's clear to me that those
who make the decisions here are quite strongly of a very different opinion
than I am and I don't think there's any prospect of anybody in this
thread, including me, changing their minds.

[gentoo-dev] Re: last rites: sys-fs/eudev

[Madhu]

* Rich Freeman <CAGfcS_neh=gu+16mo7gLRWVtHoSs2hBirvFVR_G50yJWRckHGQ@mail.gmail.com> :
Wrote on Tue, 12 Sep 2023 05:18:51 -0400:
> On Mon, Sep 11, 2023 at 10:34 PM orbea <orbea@riseup.net> wrote:
>> 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.
> As a complete outsider, I think this conversation is focusing on the
> wrong issue.
>
> IMO the main reason it is getting treecleaned is the lack of a
> maintainer.  Everything about this entire back-and-forth screams
> lack-of-maintainer.

One of the planned consequences of this tree-cleaning is the removal
of genkernel, and the use of genkernel to build gentoo's initramfs.

Genkernel uses eudev for udev, and it works because eudev can be built
statically.

systemd-udev cannot be built as a static binary again presumably a
carefully thought out design decision behind its design and
philosophy.

eudev works perfectly well for the job genkernel does, udev is not a
drop-in replacement for udev in genkernel initramfs because it doesn't
support static compilation.  Removing eudev leads to a roadmap to
deprecate genkernel last-rite and remove it.

I know you are a dracut user, but I've been unable to use dracut with
1. cryptsetup swap + swsuspend + zfs on root.  Gentoo actively removes
support for individual configurations, and only supports is for
configurations that fedora has already engineered and controls because
that is where the devs seem to be coming from.

Re: [gentoo-dev] Re: last rites: sys-fs/eudev

[Alex Boag-Munroe]

On Thu, 14 Sept 2023 at 01:20, Madhu <enometh@meer.net> wrote:
>
> * Rich Freeman <CAGfcS_neh=gu+16mo7gLRWVtHoSs2hBirvFVR_G50yJWRckHGQ@mail.gmail.com> :
> Wrote on Tue, 12 Sep 2023 05:18:51 -0400:
> > On Mon, Sep 11, 2023 at 10:34 PM orbea <orbea@riseup.net> wrote:
> >> 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.
> > As a complete outsider, I think this conversation is focusing on the
> > wrong issue.
> >
> > IMO the main reason it is getting treecleaned is the lack of a
> > maintainer.  Everything about this entire back-and-forth screams
> > lack-of-maintainer.
>
> One of the planned consequences of this tree-cleaning is the removal
> of genkernel, and the use of genkernel to build gentoo's initramfs.
>
> Genkernel uses eudev for udev, and it works because eudev can be built
> statically.
>
> systemd-udev cannot be built as a static binary again presumably a
> carefully thought out design decision behind its design and
> philosophy.
>
> eudev works perfectly well for the job genkernel does, udev is not a
> drop-in replacement for udev in genkernel initramfs because it doesn't
> support static compilation.  Removing eudev leads to a roadmap to
> deprecate genkernel last-rite and remove it.

genkernel doesn't use eudev from ::gentoo it uses its own private copy.


> Gentoo actively removes support for individual configurations, and only
> supports is for configurations that fedora has already engineered and
> controls because that is where the devs seem to be coming from.

What the actual hell are you on about

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

Andrew Ammerlaan wrote:
<snip>
> 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.
<snip>

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.

The consensus of this thread appears to be that there appears to be no
realistic prospect in sight of eudev being compatible with current and
future versions of libgudev. In view of that, I would not myself as a
maintainer ever try to push for compatibility with ligudev, and the ebuild
could come with a big fat warning that its is not compatible for anyone
wishing to install libgudev and anyone trying to force them to co-exist
would receive no support from Gentoo i.e. on their own.  I think that is
perfectly acceptable and pragmatic situation.  I know some would say this
cannot be, the package cannot pretend to be a udev provider and only
partially support the API, but I'm all for pragmatism.

However that is the worst case scenario, if a co-maintainer/upstream were
able to come up with compatibility with current/future libgudev in some
way and the community here found it acceptable then I'm fine with that
also and would co-operate with any such effort.  And if by some miracle
someone comes along upstream out of the shadows and dedicates their life
to getting eudev on par with udev over time then perhaps one day it could
again become compatible with ligudev, who knows, stranger things have
happened.

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.

Re: [gentoo-dev] Re: last rites: sys-fs/eudev

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 2804 bytes --]

Madhu <enometh@meer.net> writes:

[...snip...]
> One of the planned consequences of this tree-cleaning is the removal
> of genkernel, and the use of genkernel to build gentoo's initramfs.
>
> Genkernel uses eudev for udev, and it works because eudev can be built
> statically.
>
> systemd-udev cannot be built as a static binary again presumably a
> carefully thought out design decision behind its design and
> philosophy.

Since static linking is seldom a good idea, it is more likely that
simply nobody bothered.  I don't recall any udev components in systemd
v249 (which is the version I attempted to rebase eudev on top of) which
can't be static linked.  NSS and friends are rather disconnected from
udev-related components, and that's the closest thing I can think of to
requiring shared objects (note, *not* the same as being unusable in a
static-linked scenario).

In addition, there's precisely zero reasons why an initrd must be
composed of static linked components.

> eudev works perfectly well for the job genkernel does, udev is not a
> drop-in replacement for udev in genkernel initramfs because it doesn't
> support static compilation.  Removing eudev leads to a roadmap to
> deprecate genkernel last-rite and remove it.
>
> I know you are a dracut user, but I've been unable to use dracut with
> 1. cryptsetup swap + swsuspend + zfs on root.

I've had an LUKS2 + LVM setup which also had a swap file for suspend
with Dracut a few years back.  You should be able to declare what files
need to be brought up on the cmdline or in the config and have it do the
rest.  I've lost the notes on how exactly I did that since this was
years ago, but I recall that all the information came from
dracut.cmdline(7) (yeah, I know, manpages, unfortunate..), and I recall
needing rd.luks.uuid=, resume=, and presumably root=zfs:... in your
case.  I had my suspend a volume in LVM, though, so my resume= pointed
to /dev/foo/swap.  Please give that a shot (but keep a copy of your
current initrd so that you can retry easily).  There are plenty of
people on IRC who can help with your transition.

Dracut is more flexible than it gets credit for.

> Gentoo actively removes support for individual configurations, and
> only supports is for configurations that fedora has already engineered
> and controls because that is where the devs seem to be coming from.

Developers tend to support tools they use, and developers tend to be
more enthusiastic about tools that everyone uses and contributes to
rather than a few specific ones, produced in-house ages ago, by people
who are either no longer interested in those tools or in Gentoo.  It has
less to do with who made it and more to do with who uses it.

Have a lovely day :)
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alex Boag-Munroe]

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

Re: [gentoo-dev] Re: last rites: sys-fs/eudev

[Mike Gilbert]

On Thu, Sep 14, 2023 at 10:25 AM Arsen Arsenović <arsen@gentoo.org> wrote:
> Madhu <enometh@meer.net> writes:
> > systemd-udev cannot be built as a static binary again presumably a
> > carefully thought out design decision behind its design and
> > philosophy.
>
> Since static linking is seldom a good idea, it is more likely that
> simply nobody bothered.  I don't recall any udev components in systemd
> v249 (which is the version I attempted to rebase eudev on top of) which
> can't be static linked.

The main issue is symbol conflicts with several major projects.

systemd makes careful use of ELF symbol visibility (hidden symbols) to
prevent conflicts when libudev or libsystemd are linked with other
projects.

As I understand it, it is up to the linker to apply any visibility
rules. This doesn't work for static libs since the linker isn't
actually involved in their creation. A static library is really just
an archive with a bunch of unlinked ELF objects.

Since the symbol visibility rules are not applied, attempting to link
against libudev.a or libsystemd.a leads to symbol conflicts in
packages like LVM2 and cryptsetup. There are some Gentoo bug reports
about this, but I can't find them immediately.

The systemd project (upstream) has chosen not to work around these
conflicts by renaming symbols, and instead chooses not to support
static linking at all. They see static libs as being defective by
design. If the symbol visibility issue could be resolved at the
toolchain level, they would probably be more willing to support it.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alex Boag-Munroe]

On Thu, 14 Sept 2023 at 16:30, Eddie Chapman <eddie@ehuk.net> wrote:
>
> 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
> >>> 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.
> >> <snip>
> >>
> >> 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?
>
Have you looked at the open issues list on eudev github? It's nothing to 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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

Alex Boag-Munroe wrote:
> On Thu, 14 Sept 2023 at 16:30, Eddie Chapman <eddie@ehuk.net> wrote:
>>
>> 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 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.
>>>>>
>>>> <snip>
>>>>
>>>> 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?
>>
> Have you looked at the open issues list on eudev github? It's nothing to
> 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
>

Yes I've looked at the open issues and yes it's not perfect but apart from
the libgudev/API issue there is nothing that stops it "working fine" in
the vast majority of use cases.

I have a very strong view that nobody can tell any other person that they
should not run some piece of software no matter what the reason, technical
or non-technical. I just find it absolutely deplorable that anyone should
try and do that. (However, I would always defend anyone's right to do so,
I just strongly disagree with it). In my view, just about the only valid
reason to say to someone "you should not run that" is if it is completely
broken (e.g. in the sense that it would take an extraordinary effort to
get it to build, severe run time errors)

The fact is that people might choose to run one piece of software over
another for all kinds of reasons including non-technical ones to do with
licensing, moral/political beliefs, they like/dislike the developer or the
crown or the logo, the list can go on, and trying to judge those
non-technical reasons I think is unacceptable.

Yes eudev is not on par with udev in terms of API offering and yes it is
arguably technically inferior, and there are bugs, and whatever other
issues, but for christ sake if people want to run the damn thing just let
them be! And even if it's just because they despise systemd then so what?!
As I've argued before I don't think anyone can say hand on heart they've
always chosen a piece of software to use from a number of alternatives
purely based on it being the most "superior" technically. As long as it
builds and runs and serves someone's purpose, is not completely abandoned
with no hope of any security vulnerability ever being addressed then it's
good enough.

And I know the next objection someone might make is well that may be, but
then don't expect everyone else to do the work or bend over backwards if
you want to do something that I deem in my infinite wisdom is stupid.
Well, I'm not. The default situation for anyone with what I am proposing
is that they will not have eudev installed. But for those that want to,
for whatever reason, they will at least be able to, even if they might
have a bumpy ride, or sacrifice functionality, or some other software they
might want that has become incompatible due to API issues.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alex Boag-Munroe]

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Matt Turner]

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

Alex Boag-Munroe wrote:
<snip>
> 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.
<snip>

At the end of the day if keeping it causes so much grief for devs on bz,
irc or elsewhere then fair enough I accept that, if that would really be
the case, I'd never want to advocate something that comes with too a high
a cost from that point of view.  If the majority of Gentoo's devs just
don't want it around causing headache after headache that's a valid reason
to get rid of it.  However, I believe what I'm proposing would not have
the result you're predicting as it would no longer be falsely promising
something it cannot deliver, as desktop use would not be supported (unless
someone comes up with a way of making that work acceptably of course) yet
and maybe never.  Maybe there would even need to be a (shock,horror) dirty
hack with regards pkgconf (ok now I'm probably really going to get kicked
out for suggesting that)

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

Matt Turner wrote:
> 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.

I didn't ask for any such permission, why on earth would I do that?

> Please focus on that (if you want) and less on filling our inboxes.

Hey if other people stop replying to things on this thread then I will
too, I'm not going to just reply to myself ad finitum. If you're not
interested in this topic then filter my friend, no one's forcing you to
read it.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Rich Freeman]

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.

-- 
Rich

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alex Boag-Munroe]

On Thu, 14 Sept 2023 at 18:20, Eddie Chapman <eddie@ehuk.net> wrote:
<snip>
> However, I believe what I'm proposing would not have
> the result you're predicting as it would no longer be falsely promising
> something it cannot deliver,
>
So you propose to uncouple it as a provider of virtual/libudev? What's
your plan for things that depend on that?

--
Ninpo

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

Rich Freeman wrote:
> 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.

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Eddie Chapman]

Alex Boag-Munroe wrote:
> On Thu, 14 Sept 2023 at 18:20, Eddie Chapman <eddie@ehuk.net> wrote:
> <snip>
>
>> However, I believe what I'm proposing would not have
>> the result you're predicting as it would no longer be falsely promising
>> something it cannot deliver,
>>
> So you propose to uncouple it as a provider of virtual/libudev? What's
> your plan for things that depend on that?
>

Perhaps a solution using a use flag might be needed. Maybe "oldapi",
default unset of course. I don't know, I'm sure there will be things to
work out if this is going to be attempted, and ultimately if it's
impossible to do entirely within the package itself (I'm certainly not
proposing something that needs changes all over the place or in other
packages to work) well then it can't be done and that's that.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alex Boag-Munroe]

On Thu, 14 Sept 2023 at 18:40, Eddie Chapman <eddie@ehuk.net> wrote:
>
> 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.
>
The point of having ::gentoo is a collection of packages to make it
easy for users at large to install useful software so that they may
have and use a functional system, including people not skilled enough
to want or care for their own overrides. Such facilities have
expectations such as "things in this repo either work together or are
drop in replacements for X feature/Y software".

There's nothing stopping you or anyone, right now, doing what you
sarcastically suggest above for things that aren't practical to have
in ::gentoo.

--
Ninpo

Re: [gentoo-dev] last rites: sys-fs/eudev

[Rich Freeman]

On Thu, Sep 14, 2023 at 1:39 PM Eddie Chapman <eddie@ehuk.net> wrote:
>
> 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?

This is a fair question, but I think you're missing how most FOSS work
gets done in practice. Look at this list.  95% of it are FYIs from
devs talking about the work they've already done.  "I've introduced
this new feature - here is how you need to adjust what you're doing to
take advantage of it" - and so on.

If there is discussion about hypothetical future changes, it is
typically because somebody already plans to do the work and they're
soliciting advice, or working towards council approval for a breaking
change (ie a change that impacts other packages in the repo).

In any case, most of the reactions on this list were probably
anticipated before eudev was masked, so the discussion isn't really
informing any decisions.

As I said before the thing that would be most likely to change the
course of events is somebody stepping up to maintain things, and if
that happens it probably won't involve much discussion on the list
anyway.  They'd just fix things.

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

Actually, I would kind-of prefer if Gentoo were organized in just such
a way, but to make it practical the package manager would need a bit
of enhancement (such as letting users prioritize repositories at the
individual package level, a reasonable system of cross-repo
dependencies, and better tools for tagging repos and communicating the
QA standards for them and taking this into consideration when
syncing).

You won't see me badgering the portage team to make it possible
though, because that would be a lot of work, and if I cared about it
that much I'd be just asking for a few guidelines and making my own
PRs.

-- 
Rich

Re: [gentoo-dev] Re: last rites: sys-fs/eudev

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]


Mike Gilbert <floppym@gentoo.org> writes:

> On Thu, Sep 14, 2023 at 10:25 AM Arsen Arsenović <arsen@gentoo.org> wrote:
>> Madhu <enometh@meer.net> writes:
>> > systemd-udev cannot be built as a static binary again presumably a
>> > carefully thought out design decision behind its design and
>> > philosophy.
>>
>> Since static linking is seldom a good idea, it is more likely that
>> simply nobody bothered.  I don't recall any udev components in systemd
>> v249 (which is the version I attempted to rebase eudev on top of) which
>> can't be static linked.
>
> The main issue is symbol conflicts with several major projects.
>
> systemd makes careful use of ELF symbol visibility (hidden symbols) to
> prevent conflicts when libudev or libsystemd are linked with other
> projects.
>
> As I understand it, it is up to the linker to apply any visibility
> rules. This doesn't work for static libs since the linker isn't
> actually involved in their creation. A static library is really just
> an archive with a bunch of unlinked ELF objects.
>
> Since the symbol visibility rules are not applied, attempting to link
> against libudev.a or libsystemd.a leads to symbol conflicts in
> packages like LVM2 and cryptsetup. There are some Gentoo bug reports
> about this, but I can't find them immediately.
>
> The systemd project (upstream) has chosen not to work around these
> conflicts by renaming symbols, and instead chooses not to support
> static linking at all. They see static libs as being defective by
> design. If the symbol visibility issue could be resolved at the
> toolchain level, they would probably be more willing to support it.

We can entertain the useless idea of static linking by trying partial
linking.  I can give that a shot later.  Thanks for the background.

Have a lovely day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

On 9/14/23, Alex Boag-Munroe <ninpo@qap.la> wrote:
> 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. If we start
removing packages like this, gentoo will become source-based arch.
What is the problem here? It's not like someone who doesn't know what
they are doing can install eudev by mistake. One has to explicitly
chose to use eudev.
So what is the problem with keeping the package in ::gentoo. Mask it
if you must, like opentmpfiles, but don't remove it.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alex Boag-Munroe]

On Thu, 14 Sept 2023 at 19:39, Alexe Stefan <stefanalexe48@gmail.com> wrote:
>
> Gentoo is about choice, and we should keep it that way.

It's about viable choice.

> So what is the problem with keeping the package in ::gentoo.

You mean other than all the reasons/problems given? You not liking
them doesn't make them less valid.

--
Ninpo

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 2544 bytes --]


"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 Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

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

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexey Sokolov]

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

-- 
Best regards,
Alexey "DarthGandalf" Sokolov

Re: [gentoo-dev] last rites: sys-fs/eudev

[orbea]

On Fri, 15 Sep 2023 19:38:27 +0100
Alexey Sokolov <alexey+gentoo@asokolov.org> wrote:

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

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

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 3061 bytes --]


orbea <orbea@riseup.net> writes:

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

Indeed.

> Oh, thanks for clarifying my misunderstanding. After re-reading I don't
> know if eudev needs to be reforked, ...

It does.  It's been at least six years.  The current MO (which is to
wait for a problem then cherry pick or copy in a fix) is inefficient,
ineffective, and requires /known problems/ to reappear.

> ... missing functionality that downstreams are using can be added...

Doing this via reimplementation is a waste of effort.

> ... and otherwise focus on cleaning up and improving the code
> independently of systemd. For instance there is no reason that
> LibreSSL should refork OpenSSL.

These are apples and oranges.  OpenSSLs code is significantly worse than
systemd code.  There has also been no major improvement to code in eudev
over upstream counterparts.  I can point to one systemic issue in
systemd code (overuse of VLAs/alloca), which is actively being corrected
(but not in eudev, because it's on life support, rather than being
maintained).

Note that I'm not saying this as solely a Gentoo developer, I'm saying
this because I know what the state of the eudev project is and what it
takes to refork (since I've partly done so), and the advantages and
disadvantages of both the current approach and the one I suggest, and I
see _no_ reason to continue as the project does today.
systemd-utils[udev] is simply the easiest implementation of what I
preach.

Please attempt to bring eudev up to snuff via copying and cherry-picking
before setting your mind on continuing the status quo.  I guarantee that
less time would be spent reforking.  Supporting eudev will be clearly
useful only when that happens.

Have a lovely night.

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


-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

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

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 3615 bytes --]


orbea <orbea@riseup.net> writes:

> I just want to reiterate that the overlay suggestion is bad and the
> LibreSSL overlay is a good example of why.

No it's not.  It is not possible to compare a virtual provider against
something hard coded into many packages.

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

This only happens due to LibreSSLs failure to be useful
(i.e. compatible).

It is significantly harder to do a LibreSSL overlay as OpenSSL reverse
deps that are being hoisted into using libs that they are not compatible
with reference dev-libs/openssl directly rather than a virtual or two.

  ~/gentoo/repo$ git grep -F dev-libs/openssl | wc -l
  1685
  ~/gentoo/repo$ git grep -F sys-apps/systemd-utils | wc -l
  30

The virtuals are going nowhere.  They still have at least two providers,
even without eudev.

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

They provide different things.  Also, virtuals are extraordinarily low
maintenance.

> sys-kernel/genkernel (?)

I don't see why.

> sys-fs/udev-init-scripts
> sys-fs/mdadm
> net-wireless/bluez

I don't see why (if eudev stays useful by staying compatible).

> sys-apps/systemd-utils

I don't follow.  Wouldn't one just need to add a blocker between eudev
and systemd-utils[udev]?  That can be done in either package, and so,
can be done in the eudev one.

Please elaborate on all of the above.

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

And there is literally no developer (AFAIK) interested in dealing with
this, because eudev is _useless_, and the effort for it is nonzero.  The
effort for it can be made very close to zero if upstream was reforked
and maintained so that it's close to up-upstream.  Doing so would also
benefit a handful of other distros such as Void, Alpine and Devuan.

If there are minor changes to make for eudev that cannot be made in
upstream build systems (see, for instance, the few patches I did for
basu) then that means eudev has failed to do its job.

Basu is actually a decent example of how a 'reductionist' fork of
systemd ought to look like (note that basu is orders of magnitude
simpler, though, so the effort for eudev would still be higher).

Have a lovely night.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

[Oskari Pirhonen]

[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

[Sam James]

Oskari Pirhonen <xxc3ncoredxx@gmail.com> writes:

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

FTR: since then, the Portage logic got fixed but I also used it as
impetus to implement a bunch of tests for the news item logic which
would've caught this and a few other problems.

But definitely possible this happened here.

>
> - Oskari
>
> [[End of PGP Signed Part]]

Re: [gentoo-dev] last rites: sys-fs/eudev

[Dale]

Sam James wrote:
> Oskari Pirhonen <xxc3ncoredxx@gmail.com> writes:
>
>> [[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.
> FTR: since then, the Portage logic got fixed but I also used it as
> impetus to implement a bunch of tests for the news item logic which
> would've caught this and a few other problems.
>
> But definitely possible this happened here.
>
>> - Oskari
>>
>> [[End of PGP Signed Part]]
>


Maybe this won't happen again since some changes have been made.  Could
be there was a glitch at that time.  I also monitor -dev so that I can
have a heads up for future changes.  That said, I usually wait until I
see the news item to actually take action.  Sometimes there may need to
be changes in the tree before taking action.  When the news item shows
up, those changes are usually made.  It's time to act on it. 

Thanks for the info.

Dale

:-)  :-)

Re: [gentoo-dev] last rites: sys-fs/eudev

[David Seifert]

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

On 9/16/23, David Seifert <soap@gentoo.org> wrote:
> 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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]


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ć

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

On 9/17/23, Arsen Arsenović <arsen@gentoo.org> wrote:
>
> 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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]


Alexe Stefan <stefanalexe48@gmail.com> writes:

> Upstream, it's maintained.

See my other emails for an explanation of why looking at a commit graph
is not good enough to tell if something is maintained.

> Downstream, 2 people volunteered.

And proposed ugly 'fixes' (read: hacks).

> So it is maintained.
>
> The incompatibilities are for some desktop specific situations, and
> there is a pr upstream(hacky, but work in progress).

No they aren't.  The APIs eudev is missing (and stubs now) are not in
any way specific to desktop.  I also don't buy that desktop-server
dichotomies exist.

> For servers, or minimal desktops(which is what I expect gentoo is
> mostly used for), eudev is fine.

Sorry, I don't buy that an out of date fork with unfixed known bugs that
regularly trails behind with the hwdb is 'fine'.  Especially when said
fork has no improvements.

The only reason I see to use eudev is 'I prefer it out of principle'.
This is an okay reason, but it *does not* outweigh QA concerns.  As I
said before, if those were to go away, which would be most simply
achieved by reforking up-upstream there would be no reason to omit eudev
anymore, and eudev would hence be back.

I know this is viable since I already tried to do so in order to keep
eudev alive because I expected this ruckus would happen, but nobody
aired interest, and my time to waste is scarce, so I dropped the project
and started using systemd-utils[udev].

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

My last refork attempt involved a git-filter-repo based script which
reformatted the systemd repository into one that could be git-merge'd
into a tree with a build system.  This worked, and it would be easy to
keep up-to-date, but I never finished it.

Hope to review your contributions upstream soon, have a lovely day :-)
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: [gentoo-dev] last rites: sys-fs/eudev

[Alexe Stefan]

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.

Re: [gentoo-dev] last rites: sys-fs/eudev

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]


Alexe Stefan <stefanalexe48@gmail.com> writes:

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

Up to you.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]