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] metadata.xml upstream docs as reference to scientific publications/papers
> On Fri, 15 Sep 2023, Alexander Neuwirth wrote: > I am looking for a way to link scientific publications to > ebuilds/packages. The easiest, but hacky way right now is to use the > |https://doi.org/...|. Integration with > |epkginfo|/|equery meta| works nicely out of the box. However, > currently |pkgcheck| and/or the XML format complains about repeated > |lang| entries and does not allow long |lang| attributes (i.e. > |lang="inspirehep"| fails understandably). Please don't do this. The lang attribute is of type xs:language [1] so it must be a valid BCP 47 language tag. As a matter of fact, "doi" happens to be a valid tag for the Dogri language [2], but this isn't helpful either. [1] https://gitweb.gentoo.org/data/xml-schema.git/tree/metadata.xsd?id=db829cfdb40ae0a0034848cce38ee741a7c8d68c#n257 [2] https://www.loc.gov/standards/iso639-2/php/langcodes_name.php?code_ID=117
[gentoo-dev] Last rites: dev-ruby/ruby-elf
# Hans de Graaff (2023-09-15) # Not compatible with ruby31, no reverse dependencies. Last release in # 2013. Masked for removal on 2023-10-15. dev-ruby/ruby-elf signature.asc Description: This is a digitally signed message part
[gentoo-dev] metadata.xml upstream docs as reference to scientific publications/papers
Dear Larry, I am looking for a way to link scientific publications to ebuilds/packages. The easiest, but hacky way right now is to use the |https://doi.org/...|. Integration with |epkginfo|/|equery meta| works nicely out of the box. However, currently |pkgcheck| and/or the XML format complains about repeated |lang| entries and does not allow long |lang| attributes (i.e. |lang="inspirehep"| fails understandably). You can inspect a detailed example here https://github.com/gentoo/sci/pull/1216. The more sophisticated way, instead of abusing the |lang| attribute, would be another attribute, perhaps |reference|, or a new element in |upstream| instead of |doc|. Before I move forward with this idea, I would be curious to hear your thoughts on it. Best, APN OpenPGP_0xCD7F8280C916D488.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
