From: "Eddie Chapman" <eddie@ehuk.net>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] last rites: sys-fs/eudev
Date: Tue, 12 Sep 2023 20:06:32 +0100 [thread overview]
Message-ID: <f758a4f6d3cb829828377fa88fa7c837.squirrel@ukinbox.ecrypt.net> (raw)
In-Reply-To: <20230912103608.60c66d00@Akita>
orbea wrote:
> On Tue, 12 Sep 2023 20:23:49 +0300
> Alexe Stefan <stefanalexe48@gmail.com> wrote:
>
>> All this makes me wonder, what really is the reason for this shitshow.
>> Something tells me systemd and it's shims will never be without a
>> maintainer, regardless of how "popular" they are among gentoo folks. All
>> this seems like intentional crippling of systemd alternatives. I don't
>> use eudev, but I don't like seeing choice being taken away for such
>> paper-thin reasons. The "reasons" listed for the removal are "dead
>> upstream", which is false, and open "bugs", most of which are at most
>> differences in the default behavior.
>
> I see 9 issues listed for sys-fs/eudev on the Gentoo tracker.
>
> I closed 1 as invalid.
>
> https://bugs.gentoo.org/904741
>
> And submitted an upstream PR for another.
>
> https://bugs.gentoo.org/771705
> https://github.com/eudev-project/eudev/pull/261
>
> As for the rest...
>
> Possibly invalid?
>
> https://bugs.gentoo.org/667686 (Outdated?)
> https://bugs.gentoo.org/711462
>
> Possibly outdated?
>
> https://bugs.gentoo.org/713106
>
> And the last 4 need to further investigation.
>
> https://bugs.gentoo.org/851255
> https://bugs.gentoo.org/770358
> https://bugs.gentoo.org/668880
> https://bugs.gentoo.org/753134
>
>
> Surprisingly I don't see an issue for sticky-tags.
>
>> I use a static /dev. That won't just stop working after an update,
>> regardless of how much money changes hands.
>>
>> What does eudev need to do and doesn't do? From discussion in various
>> places, I understand that it must set permissions for a devtmpfs and
>> maybe create some symlinks. Does it not do that? I know that Lennart
>> wants to do everything and do it poorly, but eudev doesn't have to do
>> that too. What's the point of a for then?
>>
>> Overlays were mentioned in this thread. If we remove everything from
>> ::gentoo in favor of overlays, what is the point of ::gentoo then? Do
>> devs receive prizes based on how many useful packages they remove? Don't
>> answer that, we all already know the answer.
>>
>> There is this quote from "the doctor" on the forums that sums up all
>> the insanity:
>>
>>> As for software depending on what /dev you use, maybe he hasn't been
>>> paying >attention but there is no sane reason any userspace application
>>> should care how >the entries in /dev are made. There is also no sane
>>> reason to break your API >every few months when the good idea fairy
>>> comes to call.
>>
>> As for this:
>>
>>> Alexe Stefan <stefanalexe48@gmail.com> writes:
>>>
>>>> Must eudev be 100% compatible with all the garbage that gets shoved
>>>> into udev to stay in ::gentoo? I don't see mdev being held to that
>>>> standard.
>>
>>> Please don't top-post.
>>
>>> mdev is not a provider of virtual/libudev and doesn't pretend to be
>>> via its pkgconfig file.
>>
>> What if eudev has to pretend, not because of build or runtime
>> failures, but because of needless pesky pkgconfig checks? Should the
>> default eudev setup include virtual/libudev in package.provided? I think
>> it's better the way it is.
Number of open bugs on its own is really not a good argument for removing
a package. sys-fs/udev has about 15 open bugs currently so go figure. But
the
sticky-tags API issue, to be fair to those who argue for eudev removal, is
the main issue, rather than the open bugs.
But I want to ask: what are the obstacles to keeping eudev in tree but
effectively only for non-desktop use cases? I would love to hear specific
reasons from those who are pro-removal why eudev can't exist at least for
the server use case.
Because the sticky-tags issue only really affects desktop users. And if
some important server package comes along in future and wants to use a new
udev API feature, then implementing individual features in eudev is more
of a realistic proposition than the continual burden of implementing
everything.
I have many Gentoo server instances out there and I really can't see any
sensible reason why eudev can't continue being the udev provider in those
scenarios, and surely portage can easily handle marking eudev as not
compatible with desktop package installations. Then for desktop users the
choice is between eudev or a desktop. Granted it's not ideal but it's
better than no eudev at all in tree, and I'm sure there are other similar
situations in tree currently where the user has to make a choice between
one or the other thing.
Now I know the argument that might come back is "well sure, but who's
going to do the work needed to be able to make the choice possible?".
Well, let's see, maybe someone will volunteer, but I just want to know
first is there any insurmountable obstacle that makes that scenario not
even possible?
next prev parent reply other threads:[~2023-09-12 19:06 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 [this message]
2023-09-12 19:32 ` orbea
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=f758a4f6d3cb829828377fa88fa7c837.squirrel@ukinbox.ecrypt.net \
--to=eddie@ehuk.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