Again, systemd jumps out

[Syl20]

Hello,

Once again, today's update makes my day :

Code: Select all

!!! The following update has been skipped due to unsatisfied dependencies:

virtual/libudev:0

  selected: (virtual/libudev-232-r8:0/1::gentoo, installed)
  skipped: (virtual/libudev-251:0/1::gentoo, ebuild scheduled for merge) (see unsatisfied dependency below)

!!! All ebuilds that could satisfy ">=sys-apps/systemd-utils-251[udev,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?]" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-apps/systemd-utils-253.7::gentoo (masked by: package.mask, ~amd64 keyword)
- sys-apps/systemd-utils-253.6::gentoo (masked by: package.mask)
- sys-apps/systemd-utils-253.5::gentoo (masked by: package.mask, ~amd64 keyword)
- sys-apps/systemd-utils-252.10::gentoo (masked by: package.mask, ~amd64 keyword)
- sys-apps/systemd-utils-252.9::gentoo (masked by: package.mask)

(dependency required by "virtual/libudev-251::gentoo" [ebuild])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

Indeed, I masked all that have "systemd" in its name. Because, once again, I _really_ don't want to install whatever have "systemd" in its name. Gentoo is about choice, isn't it ?

Yes, I understand that gentoo must first work. Dependencies, and so on, and yes, I read the Github issue written into the virtual/libudev-251 ebuild. But what boring me is that, today, updating virtual/libudev seems totally useless :

Code: Select all

# echo '>=virtual/libudev-251' >>/etc/portage/package.mask/udev 
# emerge -avuDN world

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 21.69 s.


Total: 0 packages, Size of downloads: 0 KiB

Nothing to merge; quitting.

Gentoo works, then. So... why ?

[alamahant]

So basically you are using
sys-fs/eudev
?
Whatever works for you.
I remember it was being said that eudev development had ceased.
Apparently not.
So is it safe to revert back to eudev?

[Ionen]

dev-libs/libgudev now needs >=libudev-251 which eudev's libudev is not compatible with at the moment:

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

Results in the 251 version of the virtual lacking eudev until that's fixed. So either need to avoid packages that need the newer version until that's fixed, or switch to systemd-utils[udev].

[Ionen]

Whatever works for you.
I remember it was being said that eudev development had ceased.
Apparently not.
So is it safe to revert back to eudev?

There's maintenance but I'm not sure if it can be called "development" at the moment, not much been happening since last year (when 251 released) and it fell behind (not sure what else may be missing).

Maybe that now this is causing problems it'll bring attention to this though.

[sdauth]

I also use eudev and added a package mask for libudev (>=virtual/libudev-251)
How long will virtual/libudev-232-r8 remain ?

[Syl20]

dev-libs/libgudev now needs >=libudev-251 which eudev's libudev is not compatible with at the moment:
(snip)
So either need to avoid packages that need the newer version until that's fixed, or switch to systemd-utils[udev].

So one can think that libudev 251 isn't stable yet, and then shouldn't be explicitly marked as it. Moreover the packages that need the newer version seem still not stable.

Code: Select all

# equery y libgudev
Keywords for dev-libs/libgudev:
          |                               |   u     |  
          | a   a     p s     l r   a     |   n     |  
          | m   r h   p p   i o i s l m m | e u s   | r
          | d a m p p c a x a o s 3 p 6 i | a s l   | e
          | 6 r 6 p p 6 r 8 6 n c 9 h 8 p | p e o   | p
          | 4 m 4 a c 4 c 6 4 g v 0 a k s | i d t   | o
----------+-------------------------------+---------+-------
[I]237-r1 | + + + ~ + + + + ~ ~ ~ ~ ~ o ~ | 7 o 0/0 | gentoo
   238    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ | 7 o     | gentoo

Edit :

So is it safe to revert back to eudev?

That works, and my systems are stable. But this topic shows that keeping eudev is less safe than switching to systemd-udevd...

[sam_]

I've fixed the unnecessary stable keywords on virtual/libudev to minimise conflicts for people for now, but ultimately, it's still going to need to be fixed upstream in eudev.

"Gentoo is about choice" doesn't mean much if the upstream version is rotting.

[Hu]

Code: Select all

!!! All ebuilds that could satisfy ">=sys-apps/systemd-utils-251[udev,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?]" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-apps/systemd-utils-253.7::gentoo (masked by: package.mask, ~amd64 keyword)
- sys-apps/systemd-utils-253.6::gentoo (masked by: package.mask)
- sys-apps/systemd-utils-253.5::gentoo (masked by: package.mask, ~amd64 keyword)
- sys-apps/systemd-utils-252.10::gentoo (masked by: package.mask, ~amd64 keyword)
- sys-apps/systemd-utils-252.9::gentoo (masked by: package.mask)

(dependency required by "virtual/libudev-251::gentoo" [ebuild])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

Maybe you trimmed important output, but I would have expected to see here the comment explaining why it is masked. For example:

Code: Select all

# emerge -pv systemd-cron

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 13.55 s.


!!! All ebuilds that could satisfy ">=sys-apps/systemd-217" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-apps/systemd-9999::gentoo (masked by: package.mask, missing keyword)
/etc/portage/package.mask:
# Block installation of systemd on an openrc-based system.

- sys-apps/systemd-253.5::gentoo (masked by: package.mask, ~amd64 keyword)
- sys-apps/systemd-253.4::gentoo (masked by: package.mask, ~amd64 keyword)
- sys-apps/systemd-253.3-r1::gentoo (masked by: package.mask)

I find having comments like that helpful, particularly for packages where it is less obvious why a mask is necessary.

Because, once again, I _really_ don't want to install whatever have "systemd" in its name. Gentoo is about choice, isn't it ?

Yes. You have the choice to not use anything with systemd in its name, and the choice to not use any package which develops a hard dependency packages that have systemd in their name. Exercising this choice may require freezing and ultimately removing useful packages, though.

But what boring me is that, today, updating virtual/libudev seems totally useless :

For you, currently, yes. For some people, the newer virtual is required in order to pick up newer udev functionality.

[Syl20]

I've fixed the unnecessary stable keywords on virtual/libudev to minimise conflicts for people for now, but ultimately, it's still going to need to be fixed upstream in eudev.

Thank you. And yes, I understand that this situation isn't sustainable as is. But... who is responsible of it, at first ?

"Gentoo is about choice" doesn't mean much if the upstream version is rotting.

I think, but I could be wrong, that near-forcing users to update from a perfectly working and satisfying state to another which isn't, without a real reason (a security flaw, for example) doesn't look like "about choice".

Here, who is "upstream", and who do they fight against ?
Gnome (Red Hat ?) devs, against all odds or nearly, and because of their tight vision of a GNU/Linux system, already impose systemd as hard-dependency of _their_ softwares. OK, I agree, and I choose to not use _their_ softwares.
But that isn't sufficient for them. they want to prevent everybody from running anything else than _their_ softwares. And to do that, they "microsoftize" GNU/Linux basic components, again and again.
I don't run Gnome, I don't need/want systemd. My systems work, I don't want more. Yesterday, that was (almost) fine. Today, that isn't anymore. Tomorrow, thank you, that will be again. And the day after tomorrow ?

Maybe you trimmed important output, but I would have expected to see here the comment explaining why it is masked.

So I should justify myself for something I (and certainly others) suffer for years.
I just want to keep an existing system working. And, for that, I have to implement more and more twisted stuff.

Yes. You have the choice to not use anything with systemd in its name, and the choice to not use any package which develops a hard dependency packages that have systemd in their name. Exercising this choice may require freezing and ultimately removing useful packages, though.

I chose to use sysvinit openrc and eudev. And that should be sufficient to be able to use strictly nothing with systemd in its name. That should be, but that isn't.
So I resist. Strongly.

For you, currently, yes. For some people, the newer virtual is required in order to pick up newer udev functionality.

Maybe I'm wrong, but not here. Because dev-libs/libgudev isn't updated yet.

[stefan11111]

I think you're all forgetting something.
https://wiki.gentoo.org/wiki/Old_Fashio ... oo_Install

I keep asking myself, why some packages really care about how my /dev is managed.
If they only do a quick check, this should allow them to build and work:
https://github.com/stefan11111/fake-libudev
Otherwise I drop the package, as it's one of lennart's minions.

[sam_]

I think you're all forgetting something.
https://wiki.gentoo.org/wiki/Old_Fashio ... oo_Install

I keep asking myself, why some packages really care about how my /dev is managed.
If they only do a quick check, this should allow them to build and work:
https://github.com/stefan11111/fake-libudev
Otherwise I drop the package, as it's one of lennart's minions.

It's a bit different from yours, but you may find it interesting: https://github.com/illiliti/libudev-zero.

[stefan11111]

I chose to use sysvinit openrc and eudev. And that should be sufficient to be able to use strictly nothing with systemd in its name. That should be, but that isn't.
So I resist. Strongly.

What about systemd-tmpfiles?

[stefan11111]

I think you're all forgetting something.
https://wiki.gentoo.org/wiki/Old_Fashio ... oo_Install

I keep asking myself, why some packages really care about how my /dev is managed.
If they only do a quick check, this should allow them to build and work:
https://github.com/stefan11111/fake-libudev
Otherwise I drop the package, as it's one of lennart's minions.

It's a bit different from yours, but you may find it interesting: https://github.com/illiliti/libudev-zero.

I used it as a base for my fake-libudev.
My version's main purpose is to allow steam to work properly, however someone might benefit from it too.

[Hu]

"Gentoo is about choice" doesn't mean much if the upstream version is rotting.

I think, but I could be wrong, that near-forcing users to update from a perfectly working and satisfying state to another which isn't, without a real reason (a security flaw, for example) doesn't look like "about choice".

The intent of the change you protest is to allow users to update to a newer libgudev, and to have the package manager ensure that the prerequisites for that update are automatically satisfied. The Gentoo maintainers cannot reasonably predict every possible combination of locally-applied package.mask entries, and even if they could, they cannot express in the existing Gentoo Portage tree all the special cases needed to satisfy such systems.

Here, who is "upstream", and who do they fight against ?

You stated you want to use eudev. Ionen stated that eudev had an extended period of minimal activity. Given that it is meant to provide sufficient feature equivalence to udev to be used as a drop-in replacement, and that systemd-udevd was acquiring new features that eudev was not acquiring, it seems reasonable to say that eudev was rotting. Packages which need the latest udev features cannot rely on an eudev that lacks them, and if eudev development stalled such that even eudev's HEAD lacked those features, then those packages cannot rely on eudev anymore, and instead must insist on a package which offers those features, even if it has systemd in its name.

Maybe you trimmed important output, but I would have expected to see here the comment explaining why it is masked.

So I should justify myself for something I (and certainly others) suffer for years.

I find leaving such justifications helpful as documentation, yes. I was trying to encourage you to leave not just what was done, but why, so that if you need to review it in the future, you can consider whether the original reason is still valid.

I just want to keep an existing system working. And, for that, I have to implement more and more twisted stuff.

Yes. You need to do as sdauth described. Either unmask a package that satisfies the latest virtual, or mask the virtual itself. This is standard when you start using local overrides to deviate from the Gentoo Portage tree.

I chose to use sysvinit openrc and eudev. And that should be sufficient to be able to use strictly nothing with systemd in its name. That should be, but that isn't.
So I resist. Strongly.

As noted by my mask message, I also do not use systemd. You could resist politely.

For you, currently, yes. For some people, the newer virtual is required in order to pick up newer udev functionality.

Maybe I'm wrong, but not here. Because dev-libs/libgudev isn't updated yet.

The newer version is available, but yes, it is not updated for you and may never be. It depends on the virtual that you masked. Unless libgudev chooses to relax their dependency on udev features, that version constraint cannot be reduced. You must keep that virtual masked until such time as a package without systemd in its name satisfies the new virtual.

Since you choose not to use GNOME software, you probably do not need GObject bindings for libudev, and could emerge --ask --verbose --depclean dev-libs/libgudev.

[sam_]

We're also then back to this thing of:
* limited time (I have only 24 hours in a day, others might have different values) - at least for myself, my priority is doing things that benefit the most number of users, and then if I can find time for things for a smaller group, I might work on relevant bugs. And it's hard even then to find enough time to work on things which affect everybody.
* is it wrong for upstreams to use new functionality when they think it's needed?
* is there some divine right to always be able to use the latest version of software while making 0 compromises, if disagreeing with the direction of upstream travel?
* is it feasible at all (it's not) for Gentoo to support people running various combinations of older software without additional help to do that?
* complaints without anyone doing the technical work (also, any fix to eudev is going to involve refreshing the code it uses from systemd anyway (its udev component)) or patching libgudev to not need this feature

Keeping something like GNOME up to date is already a huge amount of work without someone having to then try to cater to eudev which itself is seemingly rotting again when its own upstream maintainers haven't addressed this yet. Gentoo is indeed about choice, but that doesn't mean we can both support and also test every single possible combination of setups before anything ever gets pushed to the tree either.

We do maintain a systemd-free option, which uses systemd-utils. That's a split out version of udev from systemd. eudev is simply an older version of that with a binary renamed. It's important to me that we always have that option, and I use it myself on a bunch of systems.

I don't think it does the discussion any favours at all to start talking about RH forcing things. Application developers are free to use a newer version of a library they depend upon. Nothing about this is even systemd-specific, eudev is free to provide this API if someone updates it to.

It's unclear to me what anyone in this thread is actually suggesting we do differently, other than "more work" (keeping in mind we're a distribution, not intending on forking every single piece of software in our distro which a user dislikes an element of) - which anyone is free to do. That is: in this particular case, I've destabled the new virtual to reduce pain for users, but other than that, everything is technically correct. Portage is rightly saying it can't upgrade (although, depending on the output (unclear if truncated or not?), it might be possible for it to give better output or something), and it keeps the system working. Portage is not capable of changing facts - if some software needs a newer API, someone needs to provide that newer API, or make its use optional. This happens all the time with applications and libraries.

(It's not clear to me that it's going to be sustainable to not-stable the new libudev virtual indefinitely, as at some point, new stable GNOME will require it.)

[stefan11111]

Since you choose not to use GNOME software, you probably do not need GObject bindings for libudev, and could emerge --ask --verbose --depclean dev-libs/libgudev.

+1
I use gtk3 for palemoon(and firefox-bin at times). No dev-libs/libgudev on my system.
See what is pulling dev-libs/libgudev in and maybe we can help remove it.

[Syl20]

What about systemd-tmpfiles?

Code: Select all

# cat /etc/portage/profile/package.provided 
virtual/tmpfiles-9999
# equery l '*tmp*'
 * Searching for *tmp* ...
[I-O] [  ] sys-apps/opentmpfiles-0.2-r1:0

I need libudev on my workstation because of my scanner/printers (net-print/hplip required). Moreover, as it's a laptop, I need a network manager, and the lonely almost-functional one I found is... NetworkManager. So bye-bye libudev-zero.

[Syl20]

You could resist politely.

(...)

Sorry, my words outran my thoughts, and as my main language isn't english, I certainly made mistakes above.

[GDH-gentoo]

Complaining to Gentoo developers about this feels to me like barking at the wrong tree. People should go insist to the new eudev maintainers about implementing udev_device_has_current_tag() and udev_device_get_current_tags_list_entry() in their libudev instead, or better, if they can, write them and submit the code for review...

[mrbassie]

To the bark of which tree ought we bark?

[GDH-gentoo]

To the bark of which tree ought we bark?

This way. Extra thanks from the user community for also going here.

[stefan11111]

What about systemd-tmpfiles?

Code: Select all

# cat /etc/portage/profile/package.provided 
virtual/tmpfiles-9999
# equery l '*tmp*'
 * Searching for *tmp* ...
[I-O] [  ] sys-apps/opentmpfiles-0.2-r1:0

I need libudev on my workstation because of my scanner/printers (net-print/hplip required). Moreover, as it's a laptop, I need a network manager, and the lonely almost-functional one I found is... NetworkManager. So bye-bye libudev-zero.

What about dhcpcd?

[stefan11111]

To the bark of which tree ought we bark?

I'd say to the devs that add dependencies on all the shiny new features systemd has to offer as soon as they hear about then.

[Goverp]

... What about dhcpcd?

Or wpa_supplicant and its GUI?

[Syl20]

... What about dhcpcd?

Or wpa_supplicant and its GUI?

Thank you all to help me, but I already tested several alternatives, and I have no time and not enough motivation anymore to test others. On my laptop, I have a LAN interface (so wpa_supplicant isn't sufficient), sometimes I have to switch fastly from an unknown network to another (so dhcpcd isn't appropriate), and, to complicate the affair, I use a script that loads and unloads the required kernel modules, to be absolutely sure the computer is connected on one and only one network. Even NetworkManager didn't work correctly some years ago.
Wicd worked very well, but isn't anymore, and is not maintained for years.