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 66C3B158089 for ; Tue, 12 Sep 2023 18:53:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 52BB32BC089; Tue, 12 Sep 2023 18:53:42 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0E7952BC013 for ; Tue, 12 Sep 2023 18:53:42 +0000 (UTC) Received: by mail-yb1-f174.google.com with SMTP id 3f1490d57ef6-d7eccc1b8c6so5690308276.0 for ; Tue, 12 Sep 2023 11:53:41 -0700 (PDT) X-Gm-Message-State: AOJu0YxCeTvKjpCMEVr76tW3jy0GFq65D0xwRQ7WUwX4rlx3M0+htlXx p/K0/8HzjeP+FV8OAwxkQjAv4O+KlFv4O0MYUtg= X-Google-Smtp-Source: AGHT+IFp3tNq/o1gOSliY3CzB36qv0/Sa7gl8s9nDkqd1rmTLXRZ9feK3+n+MHU+KAHtG4DFEfMZx1sTMoj3ADnyTok= X-Received: by 2002:a5b:c0c:0:b0:d0f:1f24:c620 with SMTP id f12-20020a5b0c0c000000b00d0f1f24c620mr211372ybq.9.1694544819096; Tue, 12 Sep 2023 11:53:39 -0700 (PDT) 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 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> In-Reply-To: From: Matt Turner Date: Tue, 12 Sep 2023 14:53:27 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [gentoo-dev] last rites: sys-fs/eudev To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: d93d826b-692b-48d5-a4f0-da21981c87e0 X-Archives-Hash: c87868a91732c20073a99ada6a86c326 On Tue, Sep 12, 2023 at 1:24=E2=80=AFPM 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 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 pay= ing >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 br= eak 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. > Lots of bad faith in this post. This is bad and you should feel bad.