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 A2A68158089 for ; Thu, 14 Sep 2023 15:30:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4E8FB2BC042; Thu, 14 Sep 2023 15:30:29 +0000 (UTC) Received: from james.steelbluetech.co.uk (james.steelbluetech.co.uk [92.63.139.228]) (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 E51ED2BC02A for ; Thu, 14 Sep 2023 15:30:27 +0000 (UTC) Received: from ukinbox.ecrypt.net (hq2.ehuk.net [10.0.10.2]) by james.steelbluetech.co.uk (Postfix) with ESMTP id 9901CBFC13 for ; Thu, 14 Sep 2023 16:30:26 +0100 (BST) DKIM-Filter: OpenDKIM Filter v2.10.3 james.steelbluetech.co.uk 9901CBFC13 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ehuk.net; s=default; t=1694705426; bh=tkBnSFdQpL9tRG7R6K1zoZPB9mwCCeaniInnyt1JRug=; h=In-Reply-To:References:Date:Subject:From:To:Reply-To:From; b=oSjRQ6cXgku7qnEBctVzq17WACoyJ751T+/RTjmumQ3+LwvSWr/phnW9j7CrWn+mH 4L77U+lmWA2biMuVIvtnZMGO/VMfphNJL0VOsySClVF6lDIVO/8jvjsoShyG6gwu01 Kq6VpebRe5COeIaWdnZl3kNYIsTBGlP63twr/KEUWC4puOwjPR5SjeYKzEiq3YblKh mLI3HYKq8eIa7IFB48KEiEoTsT830fY1UlNPZeKEACQDkrQzKM+E0glBEqR7bD7O9V YsIpp20DLcTvG5nmijaghSSm0XbCgkbsCepyYrWaYtUAKS8dfkp6M/dzgUVpNpJPE6 /3MEAzKQSvCCA== Message-ID: <50d2d8a5796c8f71b58747d3f23593dd.squirrel@ukinbox.ecrypt.net> In-Reply-To: References: <7802203.lOV4Wx5bFT@kona> <92dfbb91650e4fe9c82268ccddf8b0ab.squirrel@ukinbox.ecrypt.net> <4270953.Sgy9Pd6rRy@pinacolada> <25616924cf66471fbd1075753551dffa.squirrel@ukinbox.ecrypt.net> <7B549F95-5EEA-4DD3-A046-AA6F2C7B6349@gentoo.org> <5aa46e8fd2c09e8d54c6a9ec71725529.squirrel@ukinbox.ecrypt.net> <6e35ba9b-a55b-4b36-9d79-96faa5fb1dc6@gentoo.org> <0daf33d92cd33094b88c0411a16a63ac.squirrel@ukinbox.ecrypt.net> Date: Thu, 14 Sep 2023 16:30:26 +0100 Subject: Re: [gentoo-dev] last rites: sys-fs/eudev From: "Eddie Chapman" To: gentoo-dev@lists.gentoo.org User-Agent: SquirrelMail/1.5.2 [SVN] 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=utf-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang X-Archives-Salt: 50a4c3cb-1a78-4a46-8dde-a7cae9d240eb X-Archives-Hash: 1ebd22cd11cea596ac847dcba47281bd Alex Boag-Munroe wrote: > On Thu, 14 Sept 2023 at 15:17, Eddie Chapman wrote: > >> Andrew Ammerlaan wrote: >> >> >>> If someone were to step up and say they are willing to spend their >>> time and effort maintaining eudev and fixing the open issues then sure >>> we can keep it, I never said otherwise. However this package has been >>> maintainer-needed for quite a long time now and no one has stepped >>> up, at some point someone has to pull the plug. >> >> >> I am willing to help with the maintenance of eudev and field bug >> reports, either by preferably assisting another or as sole maintainer if >> that ended up being the requirement (hopefully not as FWICT there is >> already one other person volunteered). I would have time enough to be >> fully commit to this from 1st October onwards. >> >> My understanding is that in it's current form it cannot remain because >> it does not support the new API features expected by libgudev. If >> someone were to object to keep it for that reason then I'd propose to >> keep it but marked as incompatible with <= whatever version of libgudev >> introduced new API support. In this worst case scenario anyone with >> eudev currently installed would then have a choice of either >> uninstalling eudev, or uninstalling libgudev and any desktop depending >> libgudev. Then at the very least all server installations who wish to >> keep eudev could continue doing so, which I think is a much better >> outcome than all current eudev users having the proverbial rug pulled >> from under them. > > It's not really libgudev related, it just so happens that libgudev is the > first thing that's cropped up as using new features added to > systemd[udev]. > > Additionally the current proposals to "provide" such support are just > stubs or fallback calls, introducing unpredictable/surprising behaviour > for anything calling that part of the udev API. > > Which brings us back to the rationale of keeping a package in ::gentoo > that's identical in every way to some older outdated version of > systemd[udev] for the sole purpose of "it doesn't say systemd", now with > added surprises. > > A maintainer would need to be willing to uphold the "provides > virtual/libudev, honest guv" as well as deliver on the promises it makes > when it tells pkgconf what version it is. Not doing so is a support and > user headache later when more things use the new tags interface and subtle > or even not so subtle bugs creep in, new bugs get opened on b.g.o as well > as the added burden on #gentoo IRC. > > -- > Ninpo > Yes I've been following with interest the gh issue upstream detailing the stub efforts and am aware that this approach is highly undesirable to many for the reasons you mentioned. However, I think the prospect of anything in the server arena using these new API features is very slim indeed, and if individual cases arise it's easy to prevent them being installed together with eudev in the eudev ebuild, and if those cases happen to be key system packages well *then* it's game over for eudev. With my proposal people installing eudev would have to accept big caveats about it not being guaranteed to work with everything, there may be unknown bugs, etc. But the undisputable fact and reality is that right now eudev "works fine" with just about everything without any show stoppers. I know this approach will not be liked by what I would consider purists (I know not everyone would agree with that characterisation and that's fine it's purely my own opinion) who want to have an ideal world in the system but as long as it is only the eudev users this will affect (as everyone else who wants Gnome or whatever will simply not install eudev, which won't even be possible for them) I dare say people who want eudev on their system will be more than happy to accept the caveats. Obviously eudev and libgudev right now cannot co-exist. But it would be good to know; is anyone aware of any other non-desktop packages currently in tree which have shown any signs/prospect upstream of wanting use the new udev APIs?