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) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A5C49158089 for ; Wed, 13 Sep 2023 01:24:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EDF8B2BC09F; Wed, 13 Sep 2023 01:24:02 +0000 (UTC) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 9FA9F2BC014 for ; Wed, 13 Sep 2023 01:24:02 +0000 (UTC) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-5008d16cc36so10741607e87.2 for ; Tue, 12 Sep 2023 18:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qap-la.20230601.gappssmtp.com; s=20230601; t=1694568241; x=1695173041; darn=lists.gentoo.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=DZeXuISywPmT4tmwEGYcgh+SeyHd+CkhNug35G4FSQw=; b=MekYD9zwUsN3Ogrq4mzWj09q4Jg0+N8V3ehWSkDATGcMrls2ybTjN+/TQ0AuTHY8K4 dTM0WrmwKskLoU00Ao5rJt4ak3OuJ+tFnauOxXeU1MB7UdbZdj/1POVcJahyTJKql8wc IKeSJAIjLc96ALuTkCeCP3IVWdBywx0DVYtHUtAm+CxO3YC8+rnySPckuUUA4s5IECWq 3hWY0uXNsIXvjWhFt6/AQDIP3lmazyxnqqXSnZxk2CTJzQYkULX9PIEDyVwLDY7vAfU7 AOj8n2mjH+FvQ6p6htQI5UbZhmf1O8LyT0u3r2+oujIDPrz21Ih47svNLGZ1fT6swEmn qxOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694568241; x=1695173041; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=DZeXuISywPmT4tmwEGYcgh+SeyHd+CkhNug35G4FSQw=; b=WEXb75oUl6DlIuHcZ9zPdaASXzli5usOskCM2hfsi31Xlk+vIab0Z4HJJXeVTil2Nj XZHXzjsZBl8uMvAB6d+cXM7UY9PuHewdhwTyPIhTQubyQv5KjpYUyh9FqPr1EnBH8KfD b/1VIuzNnRUbVLjpLJoSCmZt+l9/IMXN08kvueRD7Qy7gjJ8uulKCcv45ca2BMp6Kk5b +rM/bKR+26z2c0WFnBgIUlkn5CPSj8B27/j/cLlsi0nZMnTBSxRqEWci1nQ0b7vLiyKN nUy3/qB1NcB1utAdp1RkW/J6nYpw46VhIQPnMQHtPl6+ntQSX9SV3roJfMCriRzTOKVQ a1cg== X-Gm-Message-State: AOJu0YxDnRoNs5bSlYA1i4SPCgsN6wU4b5MVcMNHgbPSParLf0i5rhkj 69fzBi8Z9MocsT+aaJSUa3g/WNSCM9CHuYfgY79NTeU5nqR0IFDttuQ= X-Google-Smtp-Source: AGHT+IGaDtfJUNBKLDlzXS8ozEALI9oNX3jsKtG3oMSDnpoCeye9mwwLR3Eslye1SzxoknoxwZ0jvvqBt/RkXPWKH64= X-Received: by 2002:a05:6512:686:b0:4fe:2c6:1d76 with SMTP id t6-20020a056512068600b004fe02c61d76mr970325lfe.21.1694568240799; Tue, 12 Sep 2023 18:24:00 -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 From: Alex Boag-Munroe Date: Wed, 13 Sep 2023 02:23:49 +0100 Message-ID: Subject: Re: [gentoo-dev] last rites: sys-fs/eudev To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary="0000000000000a75ab0605336ace" X-Archives-Salt: d3dbe998-b9ea-40aa-ba4e-3078eacc722d X-Archives-Hash: eea82308462871df7ac4575608ae4a5b --0000000000000a75ab0605336ace Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >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 that >>> 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 differentiate >> 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 because >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 servers >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 suitabl= y >>> qualified? Is that really going to force everyone else to modify their >>> 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 take >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 simply >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 provide >roughly the same functionality and yet we don't discard one of them simply >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 has >just been existing, providing the same functionality. There have been bug >fixes and new releases, isn't that the minimum we expect? It is certainly >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 becoming 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 submitted 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 from systemd accomplishes the goal of not having systemd "managing" your system, 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 complaints about the removal seems to be "but it's going to be HARD to maintain this 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 discussion of how to support libgudev. The PR to fix the API change is 50% "TODO" comments with fallback calls, the other 50% being a version bump and header hack. Folks have posted some absolutely heinous discussions and proposals from 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 fundamental functionality of my system and I say this as a former eudev user. eudev is no longer viable as something that provides virtual/libudev, that 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 delivering 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 this decision. Either step up as a maintainer if it matters to you so much, or maintain your own overlay if you only care about the things that matter to 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 and 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 udev 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 underwear 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 includes keeping up with upstream but also delivering on the promise that it can fulfill virtual/libudev. -- Ninpo, known idiot --0000000000000a75ab0605336ace Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>Matt Turner wrote:
>> On Tue, Sep 12, 2023 at= 5:23=C3=A2=E2=82=AC=C2=AFPM Eddie Chapman <eddie@ehuk.net> wrote:
>>
>>> Why would y= ou think that by having an alternative in tree it means that
>>>= ; everyone else is then forced into doing work that they don't want to<= br>>>> and it will inconvenience everyone?
>>
>>= Because it's already happened!
>>
>> commit 6404b064= d63d182da4a8a193533a188cdf832d41 Author: Mike Gilbert
>> <floppym@gentoo.org>
>> Dat= e: =C2=A0 Sun Jul 30 14:07:47 2023 -0400
>>
>> virtual/li= budev: add eudev and sticky-tags USE flags
>>
>> eudev la= cks API support for the new libudev functions that differentiate
>>= ; between sticky and current tags on device events.
>>
>>= Add a USE flag so we can depend on the new API from libgudev.
>><= br>>> commit 319b4ed88674af738bd3fd90e56dc06c88de15db Author: Mike Gi= lbert
>> <floppym@gentoo.= org>
>> Date: =C2=A0 Sun Jul 30 14:10:44 2023 -0400
>= >
>> dev-libs/libgudev: depend on virtual/libudev[sticky-tags]<= br>>>
>> And as a result we have had at least three bug repo= rts from users
>> complaining that they cannot update:
>>=
>> https://bugs.gentoo= .org/913702
>> http= s://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.<= br>>
>But I think I see your point that here eudev is causing prob= lems for
>Gentoo devs who are seeing perhaps an influx of users compl= aining because
>of the problem created by eudev not keeping up with u= dev API changes.
>
>However, perhaps a better approach might ha= ve been a news item informing
>users of dev-libs/libgudev i.e. deskto= p users that using eudev with
>dev-libs/libgudev is no longer going t= o be possible going forward (which
>is out of control of Gentoo) and = that they had a choice of either
>uninstalling their desktop environm= ent (if it depended on
>dev-libs/libgudev) or switching to udev.=C2= =A0 Then people who just run servers
>can continue using eudev if the= y wish, and there would be no need to
>remove it completely from the = tree.=C2=A0 This is the approach I have argued
>for earlier in this t= hread.
>
>>> What if someone came along now and said
&= gt;>> they were willing to "step up" and maintain eudev and= they were suitably
>>> =C2=A0qualified? Is that really going t= o force everyone else to modify their
>>> =C2=A0ways?
>>> 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 m= ake eudev worth
>> keeping.
>
>Yes I agree that action= s matter not words. However, maintainership does
>have to start with = at least some words such as "OK I will step up and take
>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-ut= ils[udev]?
>
>Ok granted, as of right now eudev has not added a= ny value as it has simply
>forked, made some small changes but essent= ially does the same job.
>However, again you're missing the point= , there is a very significant
>number of users who for subjective/pol= itical/whatever non-technical
>reasons want eudev instead of udev. Th= ese are valid reasons, and before
>you try and argue they are not exa= mine your own software choices and ask
>yourself if you always choose= something entirely on technical merit.
>
>And, to be honest, e= udev does not *have* to do anything different. If it
>provides roughl= y 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 ma= ny examples of alternatives of one software or another that provide
>= roughly the same functionality and yet we don't discard one of them sim= ply
>because it is not adding features that make it subjectively bett= er than
>the other one.
>
>Also, I don't think it'= ;s fair to just write the project off because it has
>just been exist= ing, providing the same functionality.=C2=A0 There have been bug
>fix= es and new releases, isn't that the minimum we expect?=C2=A0 It is cert= ainly
>not abandoned and dead as it has been characterised here. Mayb= e it will
>become a proper fork in future and add something that udev= doesn't have,
>who knows.

OK a qui= ck 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 t= hat Poettering is an arse and systemd becoming 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 submitted my fair share of bugs (and su= ggested fixes for them).

That said, eudev is no hill to die on. The = way Gentoo splits out udev from systemd accomplishes the goal of not having= systemd "managing" your system, which was the goal of eudev. Als= o the goal of eudev was to be a DROP IN REPLACEMENT for udev, this is no lo= nger the case. The thrust of the complaints about the removal seems to be &= quot;but it's going to be HARD to maintain this in an overlay" whi= ch is kinda the point of why it's being binned from ::gentoo: no one wa= nts to do that work for the Gentoo userbase.

"Works on my mach= ine" is an argument to use an overlay, not keep it in ::gentoo where w= e've already seen 3 duplicate bug reports where it _doesn't_ work o= n 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 discussion of how to support libgudev. The PR to fix the API change is= 50% "TODO" comments with fallback calls, the other 50% being a v= ersion bump and header hack. Folks have posted some absolutely heinous disc= ussions and proposals from the eudev github as "proof" it's b= eing maintained adequately. Stubs and "quick and dirty" fixes are= n't things I find suitable for such a fundamental functionality of my s= ystem and I say this as a former eudev user.

eudev is no longer viab= le as something that provides virtual/libudev, that is its entire reason fo= r 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 delivering on its drop in promise howe= ver little WHAT it doesn't satisfy concerns YOU as a complainer. For ::= gentoo the entire userbase has to be considered.

The Gentoo team des= erve precisely zero of the crap they're getting for this decision. Eith= er step up as a maintainer if it matters to you so much, or maintain your o= wn overlay if you only care about the things that matter to 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 sti= cky-tags and if you have things that depend on libgudev, mask versions that= want sticky-tags and it's an exercise for the user when that's no = longer possible.=C2=A0 I assure you at some point it will become no longer = possible.

To call back to my intro, eudev gives nothing that being a= ble to pluck udev from systemd gives, which Gentoo is able to do with aplom= b.=C2=A0 No systemd for me, openrc forever, cold dead hands etc.=C2=A0 If t= hat changes then that's a different discussion, whether eudev gets fork= ed and revived or a new udev fork happens. Until then I suggest a lot of fo= lks need to unbunch some underwear and either (in order of preference): get= over it and switch to openrc with systemd udev, =C2=A0overlay with relevan= t USE flags and self maintenance, or volunteer to maintain properly the sys= -fs/eudev package which not only includes keeping up with upstream but also= delivering on the promise that it can fulfill virtual/libudev.
<= br>
--
Ninpo, known idiot
--0000000000000a75ab0605336ace--