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 2D736158089 for ; Tue, 12 Sep 2023 17:36:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5FDD82BC083; Tue, 12 Sep 2023 17:36:22 +0000 (UTC) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 1BF982BC014 for ; Tue, 12 Sep 2023 17:36:22 +0000 (UTC) Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (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 mx1.riseup.net (Postfix) with ESMTPS id 4RlW2y1KV2zDr8G for ; Tue, 12 Sep 2023 17:36:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1694540181; bh=NpITLO/c3BhGWAWfK8WRwqAi9IpNMCr++MyC0D/M+dU=; h=Date:From:To:Subject:In-Reply-To:References:From; b=ow/miOv3Xi3bDm22bs2935qBkveAaA9bBmDNKscDk0Jfl+YRI6YyQoo3XiECO9hBO enPYd43oXZpxFW4mF7HugQ59xzCXHmHV+ieOtDaAcFNr2L758/ti5U4k6e/wk2dYfc JjbcugFPbWteWA0lJtSHfW9yQSt9u0DcoFfHxb70= X-Riseup-User-ID: BE8FACB4BD0C1BBAA77FF5A75176B64F94EFA64E7A78FA7CF27E8736B7248753 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4RlW2x69HTzFpcn for ; Tue, 12 Sep 2023 17:36:09 +0000 (UTC) Date: Tue, 12 Sep 2023 10:36:08 -0700 From: orbea To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] last rites: sys-fs/eudev Message-ID: <20230912103608.60c66d00@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> 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: 493222b1-81ca-47e7-bd85-009a68e7869c X-Archives-Hash: fda474322277cb83afb0bef05ea68aa3 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. >