Re: [gentoo-dev] last rites: sys-fs/eudev
Alexe Stefan writes:
> On 9/17/23, Arsen Arsenović 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ć
signature.asc
Description: PGP signature
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/17/23, Arsen Arsenović 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
Alexe Stefan 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ć
signature.asc
Description: PGP signature
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/17/23, Arsen Arsenović wrote: > > Alexe Stefan 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
Alexe Stefan 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ć signature.asc Description: PGP signature
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/16/23, David Seifert wrote:
> On Fri, 2023-09-15 at 15:40 -0700, orbea wrote:
>> On Fri, 15 Sep 2023 01:19:22 +0200
>> Arsen Arsenović wrote:
>>
>> > "Eddie Chapman" 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
On Fri, 2023-09-15 at 15:40 -0700, orbea wrote:
> On Fri, 15 Sep 2023 01:19:22 +0200
> Arsen Arsenović wrote:
>
> > "Eddie Chapman" 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
Sam James wrote: > Oskari Pirhonen 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
Oskari Pirhonen 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
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 signature.asc Description: PGP signature
Re: [gentoo-dev] last rites: sys-fs/eudev
orbea 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ć signature.asc Description: PGP signature
Re: [gentoo-dev] last rites: sys-fs/eudev
orbea 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ć signature.asc Description: PGP signature
Re: [gentoo-dev] last rites: sys-fs/eudev
On Fri, 15 Sep 2023 01:19:22 +0200
Arsen Arsenović wrote:
> "Eddie Chapman" 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
On Fri, 15 Sep 2023 19:38:27 +0100
Alexey Sokolov wrote:
> 15.09.2023 16:10, orbea пишет:
> > On Fri, 15 Sep 2023 01:19:22 +0200
> > Arsen Arsenović wrote:
> >
> >> "Eddie Chapman" 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
15.09.2023 16:10, orbea пишет:
On Fri, 15 Sep 2023 01:19:22 +0200
Arsen Arsenović wrote:
"Eddie Chapman" 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
On Fri, 15 Sep 2023 01:19:22 +0200
Arsen Arsenović wrote:
> "Eddie Chapman" 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
"Eddie Chapman" 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ć
signature.asc
Description: PGP signature
Re: [gentoo-dev] last rites: sys-fs/eudev
On Thu, 14 Sept 2023 at 19:39, Alexe Stefan 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
On 9/14/23, Alex Boag-Munroe wrote: > On Thu, 14 Sept 2023 at 17:50, Eddie Chapman wrote: >> > > > 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
On Thu, Sep 14, 2023 at 1:39 PM Eddie Chapman 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] last rites: sys-fs/eudev
On Thu, 14 Sept 2023 at 18:40, Eddie Chapman 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
Alex Boag-Munroe wrote: > On Thu, 14 Sept 2023 at 18:20, Eddie Chapman wrote: > > >> 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
Rich Freeman wrote: > On Thu, Sep 14, 2023 at 12:50 PM Eddie Chapman 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
On Thu, 14 Sept 2023 at 18:20, Eddie Chapman wrote: > 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
On Thu, Sep 14, 2023 at 12:50 PM Eddie Chapman 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
Matt Turner wrote: > On Thu, Sep 14, 2023 at 10:17 AM Eddie Chapman 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
Alex Boag-Munroe wrote: > 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. 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
On Thu, Sep 14, 2023 at 10:17 AM Eddie Chapman 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
On Thu, 14 Sept 2023 at 17:50, Eddie Chapman wrote: > 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
Alex Boag-Munroe wrote: > On Thu, 14 Sept 2023 at 16:30, Eddie Chapman wrote: >> >> Alex Boag-Munroe wrote: >> >>> On Thu, 14 Sept 2023 at 15:17, Eddie Chapman wrote: >>> Andrew Ammerlaan wrote: > 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. > 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
Re: [gentoo-dev] last rites: sys-fs/eudev
On Thu, 14 Sept 2023 at 16:30, Eddie Chapman wrote: > > Alex Boag-Munroe wrote: > > On Thu, 14 Sept 2023 at 15:17, Eddie Chapman wrote: > > > >> Andrew Ammerlaan wrote: > >> > >> > >>> 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. > >> > >> > >> 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
Re: [gentoo-dev] last rites: sys-fs/eudev
Alex Boag-Munroe wrote: > On Thu, 14 Sept 2023 at 15:17, Eddie Chapman wrote: > >> Andrew Ammerlaan wrote: >> >> >>> 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. >> >> >> 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
On Thu, 14 Sept 2023 at 15:17, Eddie Chapman wrote: > > Andrew Ammerlaan wrote: > > > 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. > > > 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] last rites: sys-fs/eudev
Andrew Ammerlaan wrote: > 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. 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] last rites: sys-fs/eudev
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 >>> wrote: >>> Andreas K. Huettel wrote: > * 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
Re: [gentoo-dev] last rites: sys-fs/eudev
Alexe Stefan 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ć signature.asc Description: PGP signature
Re: [gentoo-dev] last rites: sys-fs/eudev
On Wed, 13 Sept 2023 at 10:34, Alexe Stefan 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
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
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
Re: [gentoo-dev] last rites: sys-fs/eudev
On Wed, 13 Sept 2023 at 09:55, 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. 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
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
On 12/09/2023 23:23, Eddie Chapman wrote: Andrew Ammerlaan wrote: On 12 September 2023 21:47:31 CEST, Eddie Chapman wrote: Andreas K. Huettel wrote: * 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
Alexe Stefan wrote: > On 9/13/23, Dale 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/> 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 >> LNG 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. >> >> > 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
On 9/13/23, Dale 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/ 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 > LNG 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. > > 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
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/. 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 LNG 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.
Re: [gentoo-dev] last rites: sys-fs/eudev
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.
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/13/23, Eli Schwartz wrote: > On 9/13/23 1:03 AM, Alexe Stefan wrote: >> On 9/13/23, Eli Schwartz wrote: >>> On 9/13/23 12:35 AM, Alexe Stefan wrote: On 9/13/23, Matt Turner wrote: > On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan > 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
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/13/23 1:03 AM, Alexe Stefan wrote: > On 9/13/23, Eli Schwartz wrote: >> On 9/13/23 12:35 AM, Alexe Stefan wrote: >>> On 9/13/23, Matt Turner wrote: On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan 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
On 9/13/23, Eli Schwartz wrote: > On 9/13/23 12:35 AM, Alexe Stefan wrote: >> On 9/13/23, Matt Turner wrote: >>> On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan >>> 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
On 9/13/23 12:35 AM, Alexe Stefan wrote: > On 9/13/23, Matt Turner wrote: >> On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan >> 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
On 9/13/23, Matt Turner wrote: > On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan > wrote: >> >> On 9/13/23, Matt Turner wrote: >> > On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman 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 >> > 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 >> > 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
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
Re: [gentoo-dev] last rites: sys-fs/eudev
On Wed, 13 Sept 2023 at 02:23, Alex Boag-Munroe wrote: > > >Matt Turner wrote: > >> On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman 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 > >> > >> 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 > >> > >> 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
Re: [gentoo-dev] last rites: sys-fs/eudev
>Matt Turner wrote: >> On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman 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 >> >> 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 >> >> 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
Re: [gentoo-dev] last rites: sys-fs/eudev
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
Matt Turner wrote: > On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman 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 > > 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 > > 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
On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan wrote: > > On 9/13/23, Matt Turner wrote: > > On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman 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 > > 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 > > 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
On 9/13/23, Matt Turner wrote: > On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman 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 > 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 > 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
On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman 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 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 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
Andrew Ammerlaan wrote: > > On 12 September 2023 21:47:31 CEST, 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'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
Eli Schwartz wrote: > On 9/12/23 3:05 PM, orbea wrote: >> On Tue, 12 Sep 2023 14:51:34 -0400 >> Matt Turner 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
On Tue, Sep 12, 2023 at 4:25 PM orbea wrote: > > On Tue, 12 Sep 2023 14:51:34 -0400 > Matt Turner wrote: > > > On Tue, Sep 12, 2023 at 11:35 AM orbea wrote: > > > > > > On Tue, 12 Sep 2023 15:17:00 +0100 > > > Sam James wrote: > > > > > > > Rich Freeman writes: > > > > > > > > > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman > > > > > 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
On 12 September 2023 21:47:31 CEST, 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'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
On 9/12/23 3:05 PM, orbea wrote: On Tue, 12 Sep 2023 14:51:34 -0400 Matt Turner 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
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 > > > > 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 > dilfri...@gentoo.org Gentoo Linux developer > (council, toolchain, base-system, perl, libreoffice) >
Re: [gentoo-dev] last rites: sys-fs/eudev
On Tue, 12 Sep 2023 20:06:32 +0100 "Eddie Chapman" wrote: > orbea wrote: > > On Tue, 12 Sep 2023 20:23:49 +0300 > > Alexe Stefan 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 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
Re: [gentoo-dev] last rites: sys-fs/eudev
> >> I'm an outsider to Gentoo development (just a heavy user for over a > >> decade both personally and professionally) so I might have missed > >> something. I just find it puzzling. > > > > I'm not puzzled by what is going on, or by your email, because it > > happens basically anytime a high-profile package is treecleaned. Yes, > > Gentoo is about choice, but somebody has to actually do work to make > > the choices viable. There are always more people interested in using > > software than maintaining it. The frustration is completely > > understandable, but also kinda unavoidable. > > It starts to bother me that so many people straight away assume that when > someone questions things it's because they are a frustrated user The eudev experiment has failed. * It was false labeling from the start.[*] * It's barely alive and not keeping up with udev upstream. * It's effectively unmaintained in Gentoo. * You don't gain anything from using it instead of udev. (Nobody does.) So why should anyone put up the effort to package it? [*] Take something out of the systemd tarball, reapply every commit, make tiny changes so it looks different, sell it to the anti-systemd crowd. Sadly no profit, since open source... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] last rites: sys-fs/eudev
orbea wrote: > On Tue, 12 Sep 2023 20:23:49 +0300 > Alexe Stefan 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 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
On Tue, 12 Sep 2023 14:51:34 -0400 Matt Turner wrote: > On Tue, Sep 12, 2023 at 11:35 AM orbea wrote: > > > > On Tue, 12 Sep 2023 15:17:00 +0100 > > Sam James wrote: > > > > > Rich Freeman writes: > > > > > > > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman > > > > 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
On 9/12/23, Matt Turner wrote: > On Tue, Sep 12, 2023 at 1:24 PM Alexe Stefan > 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 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
On Tue, Sep 12, 2023 at 1:24 PM Alexe Stefan 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 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
On Tue, Sep 12, 2023 at 11:35 AM orbea wrote: > > On Tue, 12 Sep 2023 15:17:00 +0100 > Sam James wrote: > > > Rich Freeman writes: > > > > > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman > > > 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
On Tue, Sep 12, 2023 at 11:04 AM Eddie Chapman 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
On Tue, 12 Sep 2023 20:23:49 +0300 Alexe Stefan 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 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
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 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
On Tue, 12 Sep 2023 15:17:00 +0100 Sam James wrote: > Rich Freeman writes: > > > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman > > 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
"Eddie Chapman" writes: > martin-kokos wrote: >> --- Original Message --- >> On Tuesday, September 12th, 2023 at 3:36 PM, Eddie Chapman >> wrote: >> >>> Sam James wrote: >>> "Eddie Chapman" ed...@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
Sam James wrote: > > Rich Freeman writes: > >> On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman 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
"Eddie Chapman" writes: > Rich Freeman wrote: >> On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman 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
martin-kokos wrote: > --- Original Message --- > On Tuesday, September 12th, 2023 at 3:36 PM, Eddie Chapman > wrote: > >> Sam James wrote: >> >>> "Eddie Chapman" ed...@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
Rich Freeman wrote: > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman 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
--- Original Message --- On Tuesday, September 12th, 2023 at 3:36 PM, Eddie Chapman wrote: > Sam James wrote: > > > "Eddie Chapman" ed...@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
Rich Freeman writes: > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman 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
On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman 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
"Eddie Chapman" writes: > Sam James wrote: >> >> "Eddie Chapman" 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
Sam James wrote: > > "Eddie Chapman" 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
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
On Mon, Sep 11, 2023 at 10:34 PM orbea 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
On Mon, 11 Sep 2023 23:17:09 +0100 Sam James wrote: > orbea writes: > > > On Mon, 11 Sep 2023 22:50:13 +0100 > > Sam James wrote: > > > >> orbea writes: > >> > >> > On Mon, 11 Sep 2023 22:21:21 +0100 > >> > Sam James wrote: > >> > > >> >> orbea writes: > >> >> > >> >> > On Mon, 11 Sep 2023 21:31:30 +0100 > >> >> > Sam James wrote: > >> >> > > >> >> >> Dale writes: > >> >> >> > >> >> >> > orbea wrote: > >> >> >> >> On Mon, 11 Sep 2023 17:29:47 +0200 > >> >> >> >> "Andreas K. Huettel" 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
"Eddie Chapman" writes: > Sam James wrote: >> >> "Eddie Chapman" writes: >> >>> Sam James wrote: Dale writes: > orbea wrote: >> On Mon, 11 Sep 2023 17:29:47 +0200 >> "Andreas K. Huettel" 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
Sam James wrote: > > "Eddie Chapman" writes: > >> Sam James wrote: >>> >>> Dale writes: >>> orbea wrote: > On Mon, 11 Sep 2023 17:29:47 +0200 > "Andreas K. Huettel" 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
orbea writes: > On Mon, 11 Sep 2023 22:50:13 +0100 > Sam James wrote: > >> orbea writes: >> >> > On Mon, 11 Sep 2023 22:21:21 +0100 >> > Sam James wrote: >> > >> >> orbea writes: >> >> >> >> > On Mon, 11 Sep 2023 21:31:30 +0100 >> >> > Sam James wrote: >> >> > >> >> >> Dale writes: >> >> >> >> >> >> > orbea wrote: >> >> >> >> On Mon, 11 Sep 2023 17:29:47 +0200 >> >> >> >> "Andreas K. Huettel" 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
On Mon, 11 Sep 2023 22:50:13 +0100 Sam James wrote: > orbea writes: > > > On Mon, 11 Sep 2023 22:21:21 +0100 > > Sam James wrote: > > > >> orbea writes: > >> > >> > On Mon, 11 Sep 2023 21:31:30 +0100 > >> > Sam James wrote: > >> > > >> >> Dale writes: > >> >> > >> >> > orbea wrote: > >> >> >> On Mon, 11 Sep 2023 17:29:47 +0200 > >> >> >> "Andreas K. Huettel" 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
Alexe Stefan 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 wrote: >> 11.09.2023 22:35, Sam James пишет: >>> >>> Alexey Sokolov writes: >>> 11.09.2023 22:21, Sam James пишет: > orbea writes: > >> On Mon, 11 Sep 2023 21:31:30 +0100 >> Sam James wrote: >> >>> Dale writes: >>> orbea wrote: > On Mon, 11 Sep 2023 17:29:47 +0200 > "Andreas K. Huettel" 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
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 wrote: > 11.09.2023 22:35, Sam James пишет: >> >> Alexey Sokolov writes: >> >>> 11.09.2023 22:21, Sam James пишет: orbea writes: > On Mon, 11 Sep 2023 21:31:30 +0100 > Sam James wrote: > >> Dale writes: >> >>> orbea wrote: On Mon, 11 Sep 2023 17:29:47 +0200 "Andreas K. Huettel" 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 writes: > On Mon, 11 Sep 2023 22:21:21 +0100 > Sam James wrote: > >> orbea writes: >> >> > On Mon, 11 Sep 2023 21:31:30 +0100 >> > Sam James wrote: >> > >> >> Dale writes: >> >> >> >> > orbea wrote: >> >> >> On Mon, 11 Sep 2023 17:29:47 +0200 >> >> >> "Andreas K. Huettel" 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
11.09.2023 22:35, Sam James пишет: Alexey Sokolov writes: 11.09.2023 22:21, Sam James пишет: orbea writes: On Mon, 11 Sep 2023 21:31:30 +0100 Sam James wrote: Dale writes: orbea wrote: On Mon, 11 Sep 2023 17:29:47 +0200 "Andreas K. Huettel" 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
"Eddie Chapman" writes: > Sam James wrote: >> >> Dale writes: >> >>> orbea wrote: On Mon, 11 Sep 2023 17:29:47 +0200 "Andreas K. Huettel" 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 writes: > 11.09.2023 22:21, Sam James пишет: >> orbea writes: >> >>> On Mon, 11 Sep 2023 21:31:30 +0100 >>> Sam James wrote: >>> Dale writes: > orbea wrote: >> On Mon, 11 Sep 2023 17:29:47 +0200 >> "Andreas K. Huettel" 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
On Mon, 11 Sep 2023 22:21:21 +0100 Sam James wrote: > orbea writes: > > > On Mon, 11 Sep 2023 21:31:30 +0100 > > Sam James wrote: > > > >> Dale writes: > >> > >> > orbea wrote: > >> >> On Mon, 11 Sep 2023 17:29:47 +0200 > >> >> "Andreas K. Huettel" 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 > >> > > >> > :-) :-) > >> > >> > >
