Mailing List Archive

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 <blueness@gentoo.org>
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
Re: News item for eudev deprecation [ In reply to ]
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 <blueness@gentoo.org>
> 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
kumba@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
Re: News item for eudev deprecation [ In reply to ]
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: News item for eudev deprecation [ In reply to ]
On 8/22/21 5:00 PM, Joshua Kinard wrote:
> 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?
>

From udev-249-r2 and forward. As far as upstream goes, I don't know. I
tried in the early days talking to people, but the "fog of politics" was
too thick. I can try again.

Having said that, I have assurances from people within Gentoo that they
will help maintain those patches. I can also reach out to the
openembedded people to inform them of our interest in these patches.

I think musl has reached a sufficient weight that people beyond Gentoo
are interested in making sure it works with linux systems. I was an
early adopter of it into Gentoo, like 10 years ago now. At that time,
plugging it into a linux distro was squeezing a square peg into a round
whole. This is no longer the case.

>
>> Title: eudev retirement on 2022-01-01
>> Author: Anthony G. Basile <blueness@gentoo.org>
>> 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?

I can't address this. There are two issues: 1) making sure there is a
device manager for musl. 2) making sure there is a device manager which
is independent of systemd. My concern was the former, hence eudev. If
one day I have to use systemd on a musl system, so be it. If anyone is
concerned about the second issue, they are welcome to maintain eudev :P
My life circumstances have changed and I don't have the time or will.

>
>
>> 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?

I have not tested, but I think so since "systemd-" is used as a prefix
for files installed by sys-fs/udev.

>
>
> 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/
>
>

Thanks I will correct them.


--
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
Re: News item for eudev deprecation [ In reply to ]
>>>>> On Mon, 23 Aug 2021, Anthony G Basile wrote:

>>> **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?

> I have not tested, but I think so since "systemd-" is used as a prefix
> for files installed by sys-fs/udev.

So, we've abandoned the systemd USE flag, and I remember that one of
the arguments was that users could use INSTALL_MASK for precisely the
above mentioned directories.

Now the message is that users' systems will be broken if they had
followed our previous advice? Seriously?

Ulrich
Re: News item for eudev deprecation [ In reply to ]
On Mon, 2021-08-23 at 16:36 +0200, Ulrich Mueller wrote:
> > > > > > On Mon, 23 Aug 2021, Anthony G Basile wrote:
>
> > > > **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?
>
> > I have not tested, but I think so since "systemd-" is used as a
> > prefix
> > for files installed by sys-fs/udev.
>
> So, we've abandoned the systemd USE flag, and I remember that one of
> the arguments was that users could use INSTALL_MASK for precisely the
> above mentioned directories.
>
> Now the message is that users' systems will be broken if they had
> followed our previous advice? Seriously?
>
> Ulrich

Let assume the counterfactual for a moment here: We retained the
USE=systemd flag for all unit files and what not, so people can cleanse
themselves of the systemd units etc. without resorting to INSTALL_MASK.

How would USE=-systemd have prevented this situation? USE=-systemd would
randomly mv and sed random files so the "systemd-" prefix doesn't show
up?
Re: News item for eudev deprecation [ In reply to ]
On Mon, Aug 23, 2021 at 10:36 AM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> >>>>> On Mon, 23 Aug 2021, Anthony G Basile wrote:
>
> >>> **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?
>
> > I have not tested, but I think so since "systemd-" is used as a prefix
> > for files installed by sys-fs/udev.
>
> So, we've abandoned the systemd USE flag, and I remember that one of
> the arguments was that users could use INSTALL_MASK for precisely the
> above mentioned directories.

Well, the argument is that we don't use USE flags to prevent packages
from installing small text files. It is the same reason we don't have
an openrc USE flag to control installing init.d scripts. We're now
talking about pretty far back in history but I think this was a
general guideline before systemd even came along.

> Now the message is that users' systems will be broken if they had
> followed our previous advice? Seriously?

Did we ever officially advise people to use INSTALL_MASK at all? I
thought that was mostly a "you can keep the pieces if you break
things" option we provide. IMO the risks of people misusing it are
far greater than the possible harm of having a few hundred small text
files installed on their system, but it is there if people really want
to use it.

However, having used the option in the past shouldn't hurt anybody.
It only impacts people if they use it when they install udev, hence
the news item.

--
Rich
Re: News item for eudev deprecation [ In reply to ]
On Mon, Aug 23, 2021 at 10:46 AM David Seifert <soap@gentoo.org> wrote:
>
> Let assume the counterfactual for a moment here: We retained the
> USE=systemd flag for all unit files and what not, so people can cleanse
> themselves of the systemd units etc. without resorting to INSTALL_MASK.
>
> How would USE=-systemd have prevented this situation? USE=-systemd would
> randomly mv and sed random files so the "systemd-" prefix doesn't show
> up?

So, I think using USE=systemd to control installing units is a bad
idea, for the same reason that it is a bad idea for controlling init.d
scripts. It results in users having to rebuild half their system just
to get those files installed if they later need them.

However, the argument would be that if we had used USE=systemd to
control installing units, then users wouldn't set an INSTALL_MASK, and
thus when udev comes along it would still install everything just
fine. I doubt we'd have it rename anything - the systemd- prefix
would still apply, but since there are no INSTALL_MASKs then it
wouldn't cause any issues. The issue isn't systemd in the
filenames/paths, but users attempts to keep things from being
installed with those names/paths.

I'm not sure what exactly udev installs, but obviously install masks
might or might not cause harm depending on how specific they are. If
they are just for "*systemd*" then that would be pretty likely to
clobber important stuff. If it is just targeting systemd units in
/etc/systemd/system then that seems pretty unlikely to harm anything
if you aren't running systemd as your service manager.

I notice systemd installs udev to /lib/systemd/systemd-udevd and that
would be probably the path most likely to cause issues. Most of the
rules are under /lib/udev and so on, and there are things in the
generic lib directories. However, I'm using systemd and not the
standalone udev ebuild - it might do some things differently.

IMO if users really just want to get rid of unit files they're
probably better off masking /etc/systemd/system and
/lib/systemd/system. Most of the other stuff in that path is
installed by systemd itself, which users won't have if they're not
using it. I get that there are a lot of strong opinions in this area,
but the issues that can arise probably aren't worth the fuss except in
very extreme situations where every inode counts/etc.

--
Rich
Re: News item for eudev deprecation [ In reply to ]
On Mon, 2021-08-23 at 11:16 -0400, Rich Freeman wrote:
> On Mon, Aug 23, 2021 at 10:46 AM David Seifert <soap@gentoo.org> wrote:
> >
> > Let assume the counterfactual for a moment here: We retained the
> > USE=systemd flag for all unit files and what not, so people can
> > cleanse
> > themselves of the systemd units etc. without resorting to
> > INSTALL_MASK.
> >
> > How would USE=-systemd have prevented this situation? USE=-systemd
> > would
> > randomly mv and sed random files so the "systemd-" prefix doesn't show
> > up?
>
> So, I think using USE=systemd to control installing units is a bad
> idea, for the same reason that it is a bad idea for controlling init.d
> scripts.  It results in users having to rebuild half their system just
> to get those files installed if they later need them.
>
> However, the argument would be that if we had used USE=systemd to
> control installing units, then users wouldn't set an INSTALL_MASK, and
> thus when udev comes along it would still install everything just
> fine.  I doubt we'd have it rename anything - the systemd- prefix
> would still apply, but since there are no INSTALL_MASKs then it
> wouldn't cause any issues.  The issue isn't systemd in the
> filenames/paths, but users attempts to keep things from being
> installed with those names/paths.

Where did we ever recommend that in an official capacity? I recall
people saying this off-the-record on IRC ("...then use INSTALL_MASK if
you have to remove the units"), but removing any kind of file from the
image has a likelihood of breaking something, hence I can't imagine us
recommending this in the handbook or on OFFICIAL wiki pages.

Anyhow, that ship has already sailed ages ago with sys-auth/elogind:
https://bugs.gentoo.org/758632
Re: News item for eudev deprecation [ In reply to ]
On 8/23/21 11:05 AM, Rich Freeman wrote:
> On Mon, Aug 23, 2021 at 10:36 AM Ulrich Mueller <ulm@gentoo.org> wrote:
>>
>>>>>>> On Mon, 23 Aug 2021, Anthony G Basile wrote:
>>
>>>>> **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?
>>
>>> I have not tested, but I think so since "systemd-" is used as a prefix
>>> for files installed by sys-fs/udev.
>>
>> So, we've abandoned the systemd USE flag, and I remember that one of
>> the arguments was that users could use INSTALL_MASK for precisely the
>> above mentioned directories.
>
> Well, the argument is that we don't use USE flags to prevent packages
> from installing small text files. It is the same reason we don't have
> an openrc USE flag to control installing init.d scripts. We're now
> talking about pretty far back in history but I think this was a
> general guideline before systemd even came along.
>
>> Now the message is that users' systems will be broken if they had
>> followed our previous advice? Seriously?
>
> Did we ever officially advise people to use INSTALL_MASK at all? I
> thought that was mostly a "you can keep the pieces if you break
> things" option we provide. IMO the risks of people misusing it are
> far greater than the possible harm of having a few hundred small text
> files installed on their system, but it is there if people really want
> to use it.

I remember this discussion well. It was for those "stubborn" people who
wanted a clean system. I added to the discussion by saying "what about
embedded systems people where every file counts because of inode and
block allocation constraints" and the answer was INSTALL_MASK, not a USE
flag, for the reasons Rich stated. This was to create a openrc/systemd
agnostic system.

Having said that, I'm open to whatever solution/wording you might suggest.

>
> However, having used the option in the past shouldn't hurt anybody.
> It only impacts people if they use it when they install udev, hence
> the news item.
>


--
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
Re: News item for eudev deprecation [ In reply to ]
On Mon, 2021-08-23 at 16:36 +0200, Ulrich Mueller wrote:
> > > > > > On Mon, 23 Aug 2021, Anthony G Basile wrote:
>
> > > > **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?
>
> > I have not tested, but I think so since "systemd-" is used as a
> > prefix
> > for files installed by sys-fs/udev.
>
> So, we've abandoned the systemd USE flag, and I remember that one of
> the arguments was that users could use INSTALL_MASK for precisely the
> above mentioned directories.
>
> Now the message is that users' systems will be broken if they had
> followed our previous advice? Seriously?

I'm pretty sure we've never officially advised anyone to remove
important directories via INSTALL_MASK. INSTALL_MASK on unit
directories will not affect udev users. On the other hand, if someone
was overzealous and stripped whole /lib/systemd... no compassion from
me, sorry.

We don't go out of way to support people using USE=-* either, yet that
is certainly *less stupid* than stripping arbitrary directory trees.

--
Best regards,
Micha? Górny
Re: News item for eudev deprecation [ In reply to ]
On Mon, 23 Aug 2021 at 18:24, Micha? Górny <mgorny@gentoo.org> wrote:
> I'm pretty sure we've never officially advised anyone to remove
> important directories via INSTALL_MASK. INSTALL_MASK on unit
> directories will not affect udev users. On the other hand, if someone
> was overzealous and stripped whole /lib/systemd... no compassion from
> me, sorry.
>
> We don't go out of way to support people using USE=-* either, yet that
> is certainly *less stupid* than stripping arbitrary directory trees.

This doesn't seem like arbitrary directories at all, but rather very
targeted at specific systemd locations. It is not clear which, if any,
of the mentioned locations are needed by udev.

I have found one of my machines which was created not that many years
ago have an even more overzealous mask, which was probably arrived at
by reading some forum thread.

INSTALL_MASK="/usr/lib/systemd /etc/systemd /lib/systemd
/usr/lib/modules-load.d"

Someone mentioned /lib/systemd/systemd-udevd earlier, is this a binary
that is needed?

Cheers,
Arve
Re: News item for eudev deprecation [ In reply to ]
> On 22 Aug 2021, at 21:14, Anthony G. Basile <blueness@gentoo.org> wrote:
>
> [snip]
>
>
> Title: eudev retirement on 2022-01-01
> Author: Anthony G. Basile <blueness@gentoo.org>
> Posted: 2021-08-xx
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: sys-fs/eudev
>

Let's mention that people should double check if they're relying
on the old naming rules via the /etc/ rule in eudev?

(Suggested by tirnanog on IRC).

best,
sam
Re: News item for eudev deprecation [ In reply to ]
On 8/23/2021 12:24, Micha? Górny wrote:
> On Mon, 2021-08-23 at 16:36 +0200, Ulrich Mueller wrote:
>>>>>>> On Mon, 23 Aug 2021, Anthony G Basile wrote:
>>
>>>>> **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?
>>
>>> I have not tested, but I think so since "systemd-" is used as a
>>> prefix
>>> for files installed by sys-fs/udev.
>>
>> So, we've abandoned the systemd USE flag, and I remember that one of
>> the arguments was that users could use INSTALL_MASK for precisely the
>> above mentioned directories.
>>
>> Now the message is that users' systems will be broken if they had
>> followed our previous advice? Seriously?
>
> I'm pretty sure we've never officially advised anyone to remove
> important directories via INSTALL_MASK. INSTALL_MASK on unit
> directories will not affect udev users. On the other hand, if someone
> was overzealous and stripped whole /lib/systemd... no compassion from
> me, sorry.

Digging around, I am pretty sure I picked up the INSTALL_MASK tip from
something we put out. Only current info I can find so far is on the Wiki:

https://wiki.gentoo.org/wiki/Gentoo_Without_systemd#systemd_unit_files

History on that page goes back to 2014, but the first mention of
INSTALL_MASK looks to have been added by the edit on 22 Sep 2018 @ 19:05:
https://wiki.gentoo.org/index.php?title=Gentoo_Without_systemd&oldid=735246

However, I know I've had the INSTALL_MASK lines on several of my machines
for a few years before that. In any case, looking into my mail archives, it
appears this bike shed has been painted over a few times before:

2012: "Global Systemd USE Flag"
https://archives.gentoo.org/gentoo-dev/message/5ca98a9af71db715fa68632ec1335755

2014: "Possibility of overriding user defined INSTALL_MASK from an ebuild?"
https://archives.gentoo.org/gentoo-dev/message/c20d9ada8e05dc1707f021ff01d28802

Seems like the sane option is to just drop the INSTALL_MASK and deal with a
gaggle of systemd unit files eating up some inode space. I obviously took
umbrage once upon a time, but I guess the older you get, the less you care.

--
Joshua Kinard
Gentoo/MIPS
kumba@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
Re: News item for eudev deprecation [ In reply to ]
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

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 <blueness@gentoo.org>
> 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.
>
Re: News item for eudev deprecation [ In reply to ]
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 <blueness@gentoo.org>
>> 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
Re: News item for eudev deprecation [ In reply to ]
> On 24 Aug 2021, at 11:24, Jaco Kroon <jaco@uls.co.za> 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?

The problem is that this is a bit indirect. blueness could've easily
ended up backporting whatever commit causes your issue, if it is
indeed udev, because the idea wasn't to be frozen in time anyway;
this just kind of happened accidentally because of time commitments.

I appreciate this is going to be a huge pain to debug but reporting
this upstream is the only proper fix here.

>
> 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).

I don't doubt this happened as I know you're a persistent debugger,
although my hope is that whatever issue you hit has been solved, especially
given udev is used by Debian/Fedora/RHEL and all the rest of it. But I accept
that if this was <= 1 year ago, that argument doesn't hold quite as much water.

I suppose it'd be worth looking to see if there were any kernel or LVM2 regressions
fixed around that time too.

best,
sam
Re: News item for eudev deprecation [ In reply to ]
On 22.8.2021 23.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.
>

With its new upstream, and this post serves as a PSA to the
uninititated, I guess eudev will be kept?

https://github.com/eudev-project/eudev

-- juippis