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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C4E611580B9 for ; Tue, 24 Aug 2021 11:50:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 565DEE0A87; Tue, 24 Aug 2021 11:50:25 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 35C55E0A70 for ; Tue, 24 Aug 2021 11:50:24 +0000 (UTC) Subject: Re: [gentoo-dev] News item for eudev deprecation To: Jaco Kroon , gentoo-dev@lists.gentoo.org References: <5b725a13-c9b3-1b1c-d97a-78140b83e15c@gentoo.org> <8fb07e55-6c83-ec23-e371-868d9ad1e003@uls.co.za> From: "Anthony G. Basile" Message-ID: <5705e95c-b399-e732-0618-10ec64987ea4@gentoo.org> Date: Tue, 24 Aug 2021 07:50:19 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: <8fb07e55-6c83-ec23-e371-868d9ad1e003@uls.co.za> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Archives-Salt: 8a1f1686-3220-47ca-8bd3-8442e0cf820c X-Archives-Hash: 48596d745cc0412db4d3596e32a7ea77 On 8/24/21 6:24 AM, Jaco Kroon wrote: > Hi All, > > We run glibc based systems.  No musl.  But we don't use systemd. > > As little as a year back we still ran into issues with systemd-udev > variant breaking systems, the fix of course was to nuke it and install > eudev.  Are we certain there is nothing (eg, LVM integration was our > biggest problem resulting in really crazy impossible to debug since we > can't log in due to lvn snapshot creation/removal deadlocking with > systemd-udev - no ask me not how, all I can tell you is that eudev never > exhibited this behaviour) will break? > > Whilst I fully appreciate the difficult of all the various e* packages > (elogind, eudev etc ..) and I most certainly do not have the capacity to > maintain, and therefore I'm in full support of the concept of > deprecating eudev, I'm very, very worried about us suddenly being back > into the reboot-a-server-a-week scenario.  In the worst case we've lost > some large filesystems almost certainly due to systemd-udev (we've had a > number of filesystem crashes which was recovered with fsck, but after > ditching systemd-udev and moving to eudev about two years back on this > specific host we've had ZERO further problems other than a failed drive > or two, none of which required a hard-reset to get back to a sane state). > > Kind Regards, > Jaco I kept eudev as conservative as possible which probably explains its predictable behavior. Open bugs with the sys-fs/udev maintainers and mark it critical if it is damaging filesystems. > > On 2021/08/22 22:14, Anthony G. Basile wrote: >> Hi everyone, >> >> Yes! It is time to finally deprecate eudev! sys-fs/udev now builds >> under musl! My original purpose for maintaining eudev was because >> systemd + musl did not play well together when udev was absorbed into >> the sytemd repo. Now thanks to patches from openembedded, they do, and >> my original reason for maintaining eudev is no longer valid. So its >> time to retire eudev. It has served its purpose as a stop-gap. >> >> To me, this is a success for musl, and I would like to thank all the >> developers who have taken musl seriously enough to make this happen :) >> >> I am willing to transfer the eudev repo to another organization, but I >> will not maintain it anymore and Base System doesn't want to either. >> Let me warn people, to maintain it correctly you MUST become familiar >> with its internals and watch what systemd is doing upstream to keep up. >> This is not trivial. I learned a lot from eudev, and it did save musl >> on gentoo, but there was a period there when it was taking up almost all >> of my time. If you don't know what you're getting into, you don't want >> to take on its maintenance. >> >> >> >> Title: eudev retirement on 2022-01-01 >> Author: Anthony G. Basile >> Posted: 2021-08-xx >> Revision: 1 >> News-Item-Format: 2.0 >> Display-If-Installed: sys-fs/eudev >> >> sys-fs/udev is becoming the standard provider of udev on non-systemd >> (e.g. OpenRC) systems. Users of systemd will continue to use the udev >> services provided by the sys-apps/systemd package itself. >> >> The transition should be uneventful in most cases, but please read this >> item in full to understand some possible corner cases. >> >> eudev will be retired and removed from Gentoo on 2022-01-01. We will >> start masking eudev on 2021-10-01 and give people 3 months to prepare >> their transition. You should ensure that sys-fs/eudev is not in your >> world file by running >> >> emerge --deselect sys-fs/eudev >> >> in order for Portage to replace eudev with sys-fs/udev once the >> package.mask is in place. We fully support udev on musl, whereas uclibc >> will still have to rely on eudev before also being removed on 2022-01-01. >> >> **WARNING** >> >> If you happen to have an INSTALL_MASK with a blanket "*systemd*" glob, >> you will inevitably break your system. sys-fs/udev contains "systemd" in >> some of its filenames, hence a blanket filter rule will likely lead to a >> non-functional udev installation. >> >> Rationale >> >> The integration of udev into the systemd git repo introduced numerous >> problems for none-glibc systems, such as musl and uclibc. Several >> options were considered, and the one chosen was to fork and maintain >> udev independant of the rest of systemd. This was meant as a stop-gap >> solution until such time as the problems with systemd on musl had been >> resolved. This is now the case with patches provided by openembedded, >> and my original reason for maintaining eudev is no longer relevant. >> >> I am willing to transfer eudev to another umbrella organisation or Linux >> distribution that is willing to continue its maintenance, but >> maintaining eudev cannot be done purely through proxy-maintaining and >> requires an understanding of its internals. This is a steep learning >> curve and must be an earnest effort. For this reason, the Base System >> project has decided not to support euev as an option going forward. >> > -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA