Re: [gentoo-dev] News item for eudev deprecation
On 22/08/21 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. > Upstream systemd is still prone to use any glibc-only api they find interesting and any gcc-only feature they deem useful (as seen in a recent discussion on the musl ml this month). OpenEmbedded shares, hopefully, all our requirements regarding libc and compiler so it is good to work with them, assuming maintaining the patchset on top of udev is simpler than adding the udev changes on top of eudev. In both cases it is lots of work and I'm grateful to the people that are willing to put effort in supporting standard libcs and alternative C compilers :) lu
Re: [gentoo-dev] News item for eudev deprecation
On 8/22/2021 16: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. Which version of sys-fs/udev has the patches that allow it to replace eudev? Do these patches have any chance of being accepted by upstream? > 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. Are there any concerns about upstream one day making udev and systemd inseparable again? > 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. Will an INSTALL_MASK of "/usr/lib/systemd /etc/systemd" cause any issues? Couple of typos below: > Rationale > > The integration of udev into the systemd git repo introduced numerous > problems for none-glibc systems, such as musl and uclibc. Several s/none-glibc/non-glibc/ > 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 s/independant/independent/ > 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 s/organisation/organization/ > 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. s/euev/eudev/ -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
[gentoo-dev] News item for eudev deprecation
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: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
