From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 3404C158089 for ; Tue, 12 Sep 2023 19:32:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C01BF2BC0DC; Tue, 12 Sep 2023 19:32:44 +0000 (UTC) Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 858E92BC013 for ; Tue, 12 Sep 2023 19:32:44 +0000 (UTC) Received: from fews01-sea.riseup.net (fews01-sea-pn.riseup.net [10.0.1.109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx0.riseup.net (Postfix) with ESMTPS id 4RlYdR5h1jz9tGG for ; Tue, 12 Sep 2023 19:32:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1694547163; bh=MQoWXEPB5U5LRrdOGPTmKbna7mWHfh654i0EYtU3LAM=; h=Date:From:To:Subject:In-Reply-To:References:From; b=MYcnvH+c6W3KbCPprLUwuJHJCsPw5jmar6SgpafIcObxcJEuFMw+mM7e87T7oHKMP 2vviGIKLTERuN5hPacGkJ6x7Ne5qEqBuFMWO1slFFXBhOgu4+nLBmrx8owj+k4J35c OAwBQ/IPJD1O2Q5QNXfoYTi0VnYyT5/SylsofpVI= X-Riseup-User-ID: 8E7FCF29A385B4CED749B7E5310A529BC03314DC6903394F1B2746E4E9E0E650 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews01-sea.riseup.net (Postfix) with ESMTPSA id 4RlYdR3hCdzJpNq for ; Tue, 12 Sep 2023 19:32:43 +0000 (UTC) Date: Tue, 12 Sep 2023 12:32:42 -0700 From: orbea To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] last rites: sys-fs/eudev Message-ID: <20230912123242.4eab4ea7@Akita> In-Reply-To: References: <7802203.lOV4Wx5bFT@kona> <20230911082243.65aa85f5@Akita> <4128737.ElGaqSPkdT@kona> <20230911084231.73dd619f@Akita> <5848191c-8708-edfe-0c69-eeced3907b0d@gmail.com> <87zg1szc23.fsf@gentoo.org> <5d96d41de2f7057b42b436783678c8c4.squirrel@ukinbox.ecrypt.net> <87zg1sxu88.fsf@gentoo.org> <6aca04641c105c3fc72910fdbb7b6c01.squirrel@ukinbox.ecrypt.net> <877cowxs1c.fsf@gentoo.org> <87ledbwk5g.fsf@gentoo.org> <20230912083517.65561251@Akita> <20230912103608.60c66d00@Akita> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: a7d4f951-bc24-4d5f-8b0c-1eb700490e37 X-Archives-Hash: 87ae51dca876d7b3de7393e836ed7861 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 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? > >