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 9B58E158089 for ; Thu, 14 Sep 2023 14:17:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 454932BC03F; Thu, 14 Sep 2023 14:16:56 +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 05B9B2BC02A for ; Thu, 14 Sep 2023 14:16:55 +0000 (UTC) Received: from ukinbox.ecrypt.net (hq2.ehuk.net [10.0.10.2]) by james.steelbluetech.co.uk (Postfix) with ESMTP id DE39BBFC13 for ; Thu, 14 Sep 2023 15:16:53 +0100 (BST) DKIM-Filter: OpenDKIM Filter v2.10.3 james.steelbluetech.co.uk DE39BBFC13 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ehuk.net; s=default; t=1694701014; bh=UMPkjd/c+3lJi2Mf7GGvz51l71qjWRqp6Qoms4eKfnM=; h=In-Reply-To:References:Date:Subject:From:To:Reply-To:From; b=UPrrh9jcFDDbo0tO87g2LNm10mD8v3+PG97priTegfmsYIXksgK/jBvJ1idGszXy8 tUjI7YHC9j1R+CgZi33WBa4yhI7uZGd3xAM54ss8TVc0ulgxLmLAZtSWuQkYayaGgf d13ks0Oh2GfI84KxnmwqOi4uE/m6VQySmcUHVrFVhbokfcqroM5PIyiK7xCsfo9CQ6 dyuPig4wYo3UktIWwJk1AHGZ0CMSqXygg8JrK4U/GE8zhbE3PEdFqFHRZHNA4v7ifs X8RZCduHEvKJgh1DHxF5ljmRXfSIEmimvmcrsh9Ftg84h2sjXf1IzkEpIIoPWSGegR rADZlycIYyn1g== Message-ID: <0daf33d92cd33094b88c0411a16a63ac.squirrel@ukinbox.ecrypt.net> In-Reply-To: <6e35ba9b-a55b-4b36-9d79-96faa5fb1dc6@gentoo.org> 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> Date: Thu, 14 Sep 2023 15:16:54 +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: 3f4935db-9990-497d-8406-d9e0eb7cb826 X-Archives-Hash: 177b7d630120ff6ed896d2c9db0a6878 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. The consensus of this thread appears to be that there appears to be no realistic prospect in sight of eudev being compatible with current and future versions of libgudev. In view of that, I would not myself as a maintainer ever try to push for compatibility with ligudev, and the ebuild could come with a big fat warning that its is not compatible for anyone wishing to install libgudev and anyone trying to force them to co-exist would receive no support from Gentoo i.e. on their own. I think that is perfectly acceptable and pragmatic situation. I know some would say this cannot be, the package cannot pretend to be a udev provider and only partially support the API, but I'm all for pragmatism. However that is the worst case scenario, if a co-maintainer/upstream were able to come up with compatibility with current/future libgudev in some way and the community here found it acceptable then I'm fine with that also and would co-operate with any such effort. And if by some miracle someone comes along upstream out of the shadows and dedicates their life to getting eudev on par with udev over time then perhaps one day it could again become compatible with ligudev, who knows, stranger things have happened. Of course whether the Gentoo community would deem me as a suitable maintainer and be willing to accept me as such is another matter entirely.