From: orbea <orbea@riseup.net>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] last rites: sys-fs/eudev
Date: Tue, 12 Sep 2023 12:32:42 -0700 [thread overview]
Message-ID: <20230912123242.4eab4ea7@Akita> (raw)
In-Reply-To: <f758a4f6d3cb829828377fa88fa7c837.squirrel@ukinbox.ecrypt.net>
On Tue, 12 Sep 2023 20:06:32 +0100
"Eddie Chapman" <eddie@ehuk.net> wrote:
> orbea wrote:
> > On Tue, 12 Sep 2023 20:23:49 +0300
> > Alexe Stefan <stefanalexe48@gmail.com> wrote:
> >
> >> All this makes me wonder, what really is the reason for this
> >> shitshow. Something tells me systemd and it's shims will never be
> >> without a maintainer, regardless of how "popular" they are among
> >> gentoo folks. All this seems like intentional crippling of systemd
> >> alternatives. I don't use eudev, but I don't like seeing choice
> >> being taken away for such paper-thin reasons. The "reasons" listed
> >> for the removal are "dead upstream", which is false, and open
> >> "bugs", most of which are at most differences in the default
> >> behavior.
> >
> > I see 9 issues listed for sys-fs/eudev on the Gentoo tracker.
> >
> > I closed 1 as invalid.
> >
> > https://bugs.gentoo.org/904741
> >
> > And submitted an upstream PR for another.
> >
> > https://bugs.gentoo.org/771705
> > https://github.com/eudev-project/eudev/pull/261
> >
> > As for the rest...
> >
> > Possibly invalid?
> >
> > https://bugs.gentoo.org/667686 (Outdated?)
> > https://bugs.gentoo.org/711462
> >
> > Possibly outdated?
> >
> > https://bugs.gentoo.org/713106
> >
> > And the last 4 need to further investigation.
> >
> > https://bugs.gentoo.org/851255
> > https://bugs.gentoo.org/770358
> > https://bugs.gentoo.org/668880
> > https://bugs.gentoo.org/753134
> >
> >
> > Surprisingly I don't see an issue for sticky-tags.
> >
> >> I use a static /dev. That won't just stop working after an update,
> >> regardless of how much money changes hands.
> >>
> >> What does eudev need to do and doesn't do? From discussion in
> >> various places, I understand that it must set permissions for a
> >> devtmpfs and maybe create some symlinks. Does it not do that? I
> >> know that Lennart wants to do everything and do it poorly, but
> >> eudev doesn't have to do that too. What's the point of a for then?
> >>
> >> Overlays were mentioned in this thread. If we remove everything
> >> from ::gentoo in favor of overlays, what is the point of ::gentoo
> >> then? Do devs receive prizes based on how many useful packages
> >> they remove? Don't answer that, we all already know the answer.
> >>
> >> There is this quote from "the doctor" on the forums that sums up
> >> all the insanity:
> >>
> >>> As for software depending on what /dev you use, maybe he hasn't
> >>> been paying >attention but there is no sane reason any userspace
> >>> application should care how >the entries in /dev are made. There
> >>> is also no sane reason to break your API >every few months when
> >>> the good idea fairy comes to call.
> >>
> >> As for this:
> >>
> >>> Alexe Stefan <stefanalexe48@gmail.com> writes:
> >>>
> >>>> Must eudev be 100% compatible with all the garbage that gets
> >>>> shoved into udev to stay in ::gentoo? I don't see mdev being
> >>>> held to that standard.
> >>
> >>> Please don't top-post.
> >>
> >>> mdev is not a provider of virtual/libudev and doesn't pretend to
> >>> be via its pkgconfig file.
> >>
> >> What if eudev has to pretend, not because of build or runtime
> >> failures, but because of needless pesky pkgconfig checks? Should
> >> the default eudev setup include virtual/libudev in
> >> package.provided? I think it's better the way it is.
>
> Number of open bugs on its own is really not a good argument for
> removing a package. sys-fs/udev has about 15 open bugs currently so
> go figure. But the
> sticky-tags API issue, to be fair to those who argue for eudev
> removal, is the main issue, rather than the open bugs.
Agreed, that does seem the most pressing issue as far as I can tell,
the followup would probably be the cross-compile issue I submitted an
upstream PR for.
>
> But I want to ask: what are the obstacles to keeping eudev in tree but
> effectively only for non-desktop use cases? I would love to hear
> specific reasons from those who are pro-removal why eudev can't exist
> at least for the server use case.
>
> Because the sticky-tags issue only really affects desktop users. And
> if some important server package comes along in future and wants to
> use a new udev API feature, then implementing individual features in
> eudev is more of a realistic proposition than the continual burden of
> implementing everything.
Even with a desktop its not necessarily an issue for someone using a
minimal window manager. Everything I want works just fine on my eudev
gaming system including Steam.
The only thing in the ::gentoo repo that requires sticky-tags is
dev-libs/libgudev which I believe is mostly required by desktop
managers such as Gnome. It appears to be optional in even XFCE, but I
am not sure of the ramifications of disabling the system-info USE flag
in xfce-base/libxfce4ui.
Additionally the workaround PR proposed for the upstream eudev repo
would make libgudev happy while potentially working satisfactorily in
many cases? This would require testing I can't accomplish.
>
> I have many Gentoo server instances out there and I really can't see
> any sensible reason why eudev can't continue being the udev provider
> in those scenarios, and surely portage can easily handle marking
> eudev as not compatible with desktop package installations. Then for
> desktop users the choice is between eudev or a desktop. Granted it's
> not ideal but it's better than no eudev at all in tree, and I'm sure
> there are other similar situations in tree currently where the user
> has to make a choice between one or the other thing.
I think this is effectively accomplished here?
https://github.com/gentoo/gentoo/blob/1ba10d93746ee934fc5bd0a5089e87d897d77eee/virtual/libudev/libudev-251-r1.ebuild#L15
>
> Now I know the argument that might come back is "well sure, but who's
> going to do the work needed to be able to make the choice possible?".
> Well, let's see, maybe someone will volunteer, but I just want to know
> first is there any insurmountable obstacle that makes that scenario
> not even possible?
>
>
next prev parent reply other threads:[~2023-09-12 19:32 UTC|newest]
Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-11 15:14 [gentoo-dev] last rites: sys-fs/eudev Andreas K. Huettel
2023-09-11 15:22 ` orbea
2023-09-11 15:29 ` Andreas K. Huettel
2023-09-11 15:42 ` orbea
2023-09-11 17:25 ` martin-kokos
2023-09-11 17:45 ` orbea
2023-09-11 19:20 ` Dale
2023-09-11 20:31 ` Sam James
2023-09-11 21:14 ` orbea
2023-09-11 21:21 ` Sam James
2023-09-11 21:29 ` Alexey Sokolov
2023-09-11 21:35 ` Sam James
2023-09-11 21:43 ` Alexey Sokolov
2023-09-11 21:51 ` Alexe Stefan
2023-09-11 21:59 ` Sam James
2023-09-11 21:32 ` orbea
2023-09-11 21:50 ` Sam James
2023-09-11 22:10 ` orbea
2023-09-11 22:17 ` Sam James
2023-09-12 2:34 ` orbea
2023-09-12 9:18 ` Rich Freeman
2023-09-12 11:00 ` Alarig Le Lay
2023-09-14 0:20 ` [gentoo-dev] " Madhu
2023-09-14 0:47 ` Alex Boag-Munroe
2023-09-14 14:25 ` Arsen Arsenović
2023-09-14 14:57 ` Mike Gilbert
2023-09-14 18:15 ` Arsen Arsenović
2023-09-11 21:27 ` [gentoo-dev] " Eddie Chapman
2023-09-11 21:41 ` Sam James
2023-09-11 22:22 ` Eddie Chapman
2023-09-11 22:27 ` Sam James
2023-09-12 13:36 ` Eddie Chapman
2023-09-12 13:57 ` Sam James
2023-09-12 14:12 ` Rich Freeman
2023-09-12 14:17 ` Sam James
2023-09-12 15:04 ` Eddie Chapman
2023-09-12 18:47 ` Matt Turner
2023-09-12 15:35 ` orbea
2023-09-12 17:23 ` Alexe Stefan
2023-09-12 17:36 ` orbea
2023-09-12 19:06 ` Eddie Chapman
2023-09-12 19:32 ` orbea [this message]
2023-09-12 18:53 ` Matt Turner
2023-09-12 18:58 ` Alexe Stefan
2023-09-12 23:45 ` karl
2023-09-12 18:51 ` Matt Turner
2023-09-12 19:05 ` orbea
2023-09-12 19:56 ` Eli Schwartz
2023-09-12 20:59 ` Dale
2023-09-12 20:37 ` Matt Turner
2023-09-12 14:55 ` Eddie Chapman
2023-09-12 15:00 ` Sam James
2023-09-12 19:21 ` Andreas K. Huettel
2023-09-12 19:47 ` Eddie Chapman
2023-09-12 20:33 ` Andrew Ammerlaan
2023-09-12 21:23 ` Eddie Chapman
2023-09-12 21:36 ` Matt Turner
2023-09-12 21:45 ` Alexe Stefan
2023-09-12 21:52 ` Matt Turner
2023-09-13 4:35 ` Alexe Stefan
2023-09-13 4:56 ` Eli Schwartz
2023-09-13 5:03 ` Alexe Stefan
2023-09-13 5:38 ` Eli Schwartz
2023-09-13 6:13 ` Alexe Stefan
2023-09-13 6:19 ` Alexe Stefan
2023-09-13 6:40 ` Dale
2023-09-13 6:54 ` Alexe Stefan
2023-09-13 7:23 ` Dale
2023-09-12 22:35 ` Eddie Chapman
2023-09-13 7:55 ` Andrew Ammerlaan
2023-09-13 8:10 ` Dale
2023-09-16 6:01 ` Oskari Pirhonen
2023-09-16 6:09 ` Sam James
2023-09-16 7:15 ` Dale
2023-09-13 8:13 ` Arve Barsnes
2023-09-13 23:49 ` Eddie Chapman
2023-09-14 14:16 ` Eddie Chapman
2023-09-14 14:44 ` Alex Boag-Munroe
2023-09-14 15:30 ` Eddie Chapman
2023-09-14 16:09 ` Alex Boag-Munroe
2023-09-14 16:50 ` Eddie Chapman
2023-09-14 17:18 ` Alex Boag-Munroe
2023-09-14 18:39 ` Alexe Stefan
2023-09-14 19:11 ` Alex Boag-Munroe
2023-09-14 17:27 ` Rich Freeman
2023-09-14 17:39 ` Eddie Chapman
2023-09-14 17:52 ` Alex Boag-Munroe
2023-09-14 17:57 ` Rich Freeman
2023-09-14 23:19 ` Arsen Arsenović
2023-09-15 15:10 ` orbea
2023-09-15 18:38 ` Alexey Sokolov
2023-09-15 18:56 ` orbea
2023-09-15 22:25 ` Arsen Arsenović
2023-09-15 22:40 ` orbea
2023-09-16 1:12 ` Arsen Arsenović
2023-09-16 9:35 ` David Seifert
2023-09-16 13:32 ` Alexe Stefan
2023-09-16 22:03 ` Arsen Arsenović
2023-09-17 9:00 ` Alexe Stefan
2023-09-17 10:16 ` Arsen Arsenović
2023-09-17 17:56 ` Alexe Stefan
2023-09-17 18:38 ` Arsen Arsenović
2023-09-14 17:20 ` Eddie Chapman
2023-09-14 17:28 ` Alex Boag-Munroe
2023-09-14 17:51 ` Eddie Chapman
2023-09-14 17:19 ` Matt Turner
2023-09-14 17:24 ` Eddie Chapman
2023-09-13 2:55 ` Eli Schwartz
2023-09-13 9:05 ` Eddie Chapman
2023-09-13 9:34 ` Alexe Stefan
2023-09-13 9:43 ` Alex Boag-Munroe
2023-09-13 21:57 ` Arsen Arsenović
2023-09-12 14:31 ` martin-kokos
2023-09-12 15:00 ` Eddie Chapman
2023-09-12 15:20 ` Sam James
-- strict thread matches above, loose matches on Subject: below --
2023-09-13 1:23 Alex Boag-Munroe
2023-09-13 1:48 ` Alex Boag-Munroe
2021-11-27 0:23 [gentoo-dev] Last " Mike Gilbert
2022-08-30 9:52 ` Jaco Kroon
2022-08-30 10:27 ` Arve Barsnes
2022-08-30 12:26 ` Jaco Kroon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230912123242.4eab4ea7@Akita \
--to=orbea@riseup.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox