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 D6447158089 for ; Wed, 13 Sep 2023 01:48:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0791D2BC0A9; Wed, 13 Sep 2023 01:48:44 +0000 (UTC) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 CA92D2BC014 for ; Wed, 13 Sep 2023 01:48:43 +0000 (UTC) Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-501eec0a373so10248162e87.3 for ; Tue, 12 Sep 2023 18:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qap-la.20230601.gappssmtp.com; s=20230601; t=1694569722; x=1695174522; darn=lists.gentoo.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=6Yps05vBEkvoQGcjFIldfBZkuaUutzxTwMNFvC8r9xg=; b=GFw1CBoC80ZTIsh/qmfxmjQ441tixJF7P1Lb57jgaalfCHQL7PConHEcnr/7N3XA/E jRScqQiAhlP5JyQV0P3kdsspzSNis2x2YDv8W08EwSZYBNKkICx3dYpVbjtEVUY/OF5Z iYAiK0b8uXWbskmVPSrxTUqGvSvBsy9co2FDec6DFId88nG2vwrwnSLWObXYycTU1hH2 64n8UJQyf+AFCochD68Fw6hdVKO6lyZ+3xhl24FGMI0o7JOuLN9JLSRpQ0svRrCbD6ef gu+RGIgp6e6uqSCADR+WOaL/0tIvEdZIx88ZBdfJDOAeBzBzzG4/8F477acwCM2MFOLX 6rGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694569722; x=1695174522; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6Yps05vBEkvoQGcjFIldfBZkuaUutzxTwMNFvC8r9xg=; b=FvJmpdWo9s8dSFp0cViWAsCvKK8WDn7X7ceAocjnMuG4JpGxNTiyBTZDjnboPEY7pk JfuWPSuMoDYSKxEzJzPHUekxS9nCZ7k3kCmJCmO/Sn6V8EK/VCskrvPQNkXiTIgbgyRk tZFt0+bv6didRC+PlSohlTp9Z23C6ffDL1gqZczkZyDDJor83cG+s0nPDSDj29uDzVEp 3R3/WXql4qjo/QMjcaaPh+ysc+zd7xu/TwzXB+FNPiaYc/DbKxPeDm/9da2+67m9sJUd 1eWW0UXArvCYJskN2yOqEXLiioDm0DmOV+zo0xRAuivk8qvQUjczh5ZEEzGnDfHMlNJX U1mQ== X-Gm-Message-State: AOJu0YyfYST2Mj4zNEBcblXu7LCyvQfyD2mba/C5CfGr5N2CyL8LiNoA jC9PZ+EL0vgTsjq+vEU1lF3wHmHOYMZMIcr8TAapuD5HHTpsiBShoGw= X-Google-Smtp-Source: AGHT+IFnSLJnIMC76ixki11McawmfnMShre2dPNvh0WGWBZA+kCA5yohqfT8/wzR3Z6epXUNmvbD3VxLIW52zUms4Vc= X-Received: by 2002:a19:e01a:0:b0:500:7dc0:b0b2 with SMTP id x26-20020a19e01a000000b005007dc0b0b2mr968009lfg.28.1694569722345; Tue, 12 Sep 2023 18:48:42 -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: In-Reply-To: From: Alex Boag-Munroe Date: Wed, 13 Sep 2023 02:48:31 +0100 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: baacf4d9-f05f-446f-a2d2-a3407fab8426 X-Archives-Hash: 20ace19c824341b474658c358b95faba On Wed, 13 Sept 2023 at 02:23, Alex Boag-Munroe wrote: > > >Matt Turner wrote: > >> On Tue, Sep 12, 2023 at 5:23=C3=A2=E2=82=AC=C2=AFPM Eddie Chapman wrote: > >> > >>> Why would you think that by having an alternative in tree it means th= at > >>> everyone else is then forced into doing work that they don't want to > >>> and it will inconvenience everyone? > >> > >> Because it's already happened! > >> > >> commit 6404b064d63d182da4a8a193533a188cdf832d41 Author: Mike Gilbert > >> > >> Date: Sun Jul 30 14:07:47 2023 -0400 > >> > >> virtual/libudev: add eudev and sticky-tags USE flags > >> > >> eudev lacks API support for the new libudev functions that differentia= te > >> between sticky and current tags on device events. > >> > >> Add a USE flag so we can depend on the new API from libgudev. > >> > >> commit 319b4ed88674af738bd3fd90e56dc06c88de15db Author: Mike Gilbert > >> > >> Date: Sun Jul 30 14:10:44 2023 -0400 > >> > >> dev-libs/libgudev: depend on virtual/libudev[sticky-tags] > >> > >> And as a result we have had at least three bug reports from users > >> complaining that they cannot update: > >> > >> https://bugs.gentoo.org/913702 > >> https://bugs.gentoo.org/913900 > >> https://bugs.gentoo.org/913954 > > > >If I'm not mistaken these 3 bug reports are all from users trying to run > >their systems free of systemd, i.e. with eudev. So it is the eudev users= , > >not the udev (presumably the majority) ones who have been inconvenienced= . > > > >But I think I see your point that here eudev is causing problems for > >Gentoo devs who are seeing perhaps an influx of users complaining becaus= e > >of the problem created by eudev not keeping up with udev API changes. > > > >However, perhaps a better approach might have been a news item informing > >users of dev-libs/libgudev i.e. desktop users that using eudev with > >dev-libs/libgudev is no longer going to be possible going forward (which > >is out of control of Gentoo) and that they had a choice of either > >uninstalling their desktop environment (if it depended on > >dev-libs/libgudev) or switching to udev. Then people who just run serve= rs > >can continue using eudev if they wish, and there would be no need to > >remove it completely from the tree. This is the approach I have argued > >for earlier in this thread. > > > >>> What if someone came along now and said > >>> they were willing to "step up" and maintain eudev and they were suita= bly > >>> qualified? Is that really going to force everyone else to modify the= ir > >>> ways? > > > >> It doesn't matter what people say. It matters what they do. And so far > >> no one has done anything in more than two years to make eudev worth > >> keeping. > > > >Yes I agree that actions matter not words. However, maintainership does > >have to start with at least some words such as "OK I will step up and ta= ke > >care of it" > > > >> But the core of the issue for me is -- how is eudev even the slightest > >> bit better in any way than systemd-utils[udev]? > > > >Ok granted, as of right now eudev has not added any value as it has simp= ly > >forked, made some small changes but essentially does the same job. > >However, again you're missing the point, there is a very significant > >number of users who for subjective/political/whatever non-technical > >reasons want eudev instead of udev. These are valid reasons, and before > >you try and argue they are not examine your own software choices and ask > >yourself if you always choose something entirely on technical merit. > > > >And, to be honest, eudev does not *have* to do anything different. If it > >provides roughly the same functionality as udev (minus new APIs) then it > >serves its purpose and is good enough for those users who use it. There > >are many examples of alternatives of one software or another that provid= e > >roughly the same functionality and yet we don't discard one of them simp= ly > >because it is not adding features that make it subjectively better than > >the other one. > > > >Also, I don't think it's fair to just write the project off because it h= as > >just been existing, providing the same functionality. There have been b= ug > >fixes and new releases, isn't that the minimum we expect? It is certain= ly > >not abandoned and dead as it has been characterised here. Maybe it will > >become a proper fork in future and add something that udev doesn't have, > >who knows. > > OK a quick qualifier for me as a respondent: > > I hate systemd with a passion, a key reason I use Gentoo is openrc and I = wholeheartedly am of the belief that Poettering is an arse and systemd beco= ming defacto/ubiquitous in Linux was a dark day. I have contributed to the = gentoo repo and regularly assist in #gentoo on IRC as well as having submit= ted my fair share of bugs (and suggested fixes for them). > > That said, eudev is no hill to die on. The way Gentoo splits out udev fro= m systemd accomplishes the goal of not having systemd "managing" your syste= m, which was the goal of eudev. Also the goal of eudev was to be a DROP IN = REPLACEMENT for udev, this is no longer the case. The thrust of the complai= nts about the removal seems to be "but it's going to be HARD to maintain th= is in an overlay" which is kinda the point of why it's being binned from ::= gentoo: no one wants to do that work for the Gentoo userbase. > > "Works on my machine" is an argument to use an overlay, not keep it in ::= gentoo where we've already seen 3 duplicate bug reports where it _doesn't_ = work on their machine. The upstream "fixes" for libgudev are a stub at best= and "quick and dirty" at worst, which is a direct quote from the discussio= n of how to support libgudev. The PR to fix the API change is 50% "TODO" co= mments with fallback calls, the other 50% being a version bump and header h= ack. Folks have posted some absolutely heinous discussions and proposals fr= om the eudev github as "proof" it's being maintained adequately. Stubs and = "quick and dirty" fixes aren't things I find suitable for such a fundamenta= l functionality of my system and I say this as a former eudev user. > > eudev is no longer viable as something that provides virtual/libudev, tha= t is its entire reason for existence in the ::gentoo repo. > > I've read every single post on this thread, the comparisons to Firefox vs= Chrome are utterly ridiculous, both are regularly maintained upstream and = both still provide Web Access as people expect AND both have active package= maintainers. It is safe to say that at time of writing eudev is not delive= ring on its drop in promise however little WHAT it doesn't satisfy concerns= YOU as a complainer. For ::gentoo the entire userbase has to be considered= . > > The Gentoo team deserve precisely zero of the crap they're getting for th= is decision. Either step up as a maintainer if it matters to you so much, o= r maintain your own overlay if you only care about the things that matter t= o you, which is a lesser undertaking of work than someone keeping it viable= for ::gentoo as a whole where working behaviour MATTERS for packages that = depend on virtual/libudev. > > If it doesn't matter for you, overlay it, turn off sticky-tags and if you= have things that depend on libgudev, mask versions that want sticky-tags a= nd it's an exercise for the user when that's no longer possible. I assure = you at some point it will become no longer possible. > > To call back to my intro, eudev gives nothing that being able to pluck ud= ev from systemd gives, which Gentoo is able to do with aplomb. No systemd = for me, openrc forever, cold dead hands etc. If that changes then that's a= different discussion, whether eudev gets forked and revived or a new udev = fork happens. Until then I suggest a lot of folks need to unbunch some unde= rwear and either (in order of preference): get over it and switch to openrc= with systemd udev, overlay with relevant USE flags and self maintenance, = or volunteer to maintain properly the sys-fs/eudev package which not only i= ncludes keeping up with upstream but also delivering on the promise that it= can fulfill virtual/libudev. > > -- > Ninpo, known idiot AND ANOTHER THING... https://lists.freedesktop.org/archives/systemd-devel/2020-November/045646.h= tml <- this is not an insignificant functionality change, the tag changes are there, are significant, thus will be used and behaviour will depend on those calls being correct. Anyone still mad about last rites being issued on eudev clearly don't grasp the broad implications of half arsing compatibility for an entire user base and are just annoyed _their_ own world view doesn't match reality. Yes open source is about choices. Viable ones.