| View previous topic :: View next topic |
| Author |
Message |
Syl20
l33t
Joined: 04 Aug 2005
Posts: 619
Location: France
|
 Posted: Fri Jul 21, 2023 7:40 am Post subject: Again, systemd jumps out |
 |
|
Hello,
Once again, today's update makes my day  :
| Code: | !!! 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: | # 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 ? |
|
| Back to top |
|
 |
alamahant
Advocate
Joined: 23 Mar 2019
Posts: 3879
|
| Posted: Fri Jul 21, 2023 7:50 am Post subject: |
|
|
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?
_________________
Last edited by alamahant on Fri Jul 21, 2023 7:52 am; edited 1 time in total |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2727
|
| Posted: Fri Jul 21, 2023 7:50 am Post subject: |
|
|
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]. |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2727
|
| Posted: Fri Jul 21, 2023 7:59 am Post subject: |
|
|
| alamahant wrote: | 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. |
|
| Back to top |
|
|
sdauth
Guru
Joined: 19 Sep 2018
Posts: 572
Location: Ásgarðr
|
| Posted: Fri Jul 21, 2023 8:30 am Post subject: |
|
|
I also use eudev and added a package mask for libudev (>=virtual/libudev-251)
How long will virtual/libudev-232-r8 remain ?  |
|
| Back to top |
|
|
Syl20
l33t
Joined: 04 Aug 2005
Posts: 619
Location: France
|
| Posted: Fri Jul 21, 2023 8:47 am Post subject: |
|
|
| Ionen wrote: | 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: | # 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 :
| alamahant wrote: | | 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... |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1685
|
| Posted: Fri Jul 21, 2023 1:22 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21724
|
| Posted: Fri Jul 21, 2023 3:29 pm Post subject: Re: Again, systemd jumps out |
|
|
| Syl20 wrote: | | Code: | !!! 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: | # 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. | Syl20 wrote: | | 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. | Syl20 wrote: | | 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. |
|
| Back to top |
|
|
Syl20
l33t
Joined: 04 Aug 2005
Posts: 619
Location: France
|
| Posted: Fri Jul 21, 2023 9:27 pm Post subject: |
|
|
| sam_ wrote: | | 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 ?
| Quote: | | "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 ?
| Hu wrote: | | 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.
| Quote: | | 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.
| Quote: | | 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. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1685
|
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Fri Jul 21, 2023 10:12 pm Post subject: |
|
|
| Syl20 wrote: |
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?
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Fri Jul 21, 2023 10:14 pm Post subject: |
|
|
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.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21724
|
| Posted: Fri Jul 21, 2023 10:26 pm Post subject: |
|
|
| Syl20 wrote: | | sam_ wrote: | | "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. | Syl20 wrote: | | 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. | Syl20 wrote: | | Hu wrote: | | 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. | Syl20 wrote: | | 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. | Syl20 wrote: | 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. | Syl20 wrote: | | Hu wrote: | | 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. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1685
|
| Posted: Fri Jul 21, 2023 11:02 pm Post subject: |
|
|
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.) |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Fri Jul 21, 2023 11:47 pm Post subject: |
|
|
| Hu wrote: |
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.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
Syl20
l33t
Joined: 04 Aug 2005
Posts: 619
Location: France
|
| Posted: Sat Jul 22, 2023 11:32 am Post subject: |
|
|
| Code: | # 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.
Last edited by Syl20 on Sat Jul 22, 2023 12:00 pm; edited 1 time in total |
|
| Back to top |
|
|
Syl20
l33t
Joined: 04 Aug 2005
Posts: 619
Location: France
|
| Posted: Sat Jul 22, 2023 11:52 am Post subject: |
|
|
| Hu wrote: | | You could resist politely. |
Sorry, my words outran my thoughts, and as my main language isn't english, I certainly made mistakes above. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1549
Location: South America
|
| Posted: Sat Jul 22, 2023 2:54 pm Post subject: |
|
|
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...
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
mrbassie
l33t
Joined: 31 May 2013
Posts: 781
Location: over here
|
| Posted: Sat Jul 22, 2023 6:24 pm Post subject: |
|
|
| To the bark of which tree ought we bark? |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1549
Location: South America
|
| Posted: Sat Jul 22, 2023 6:39 pm Post subject: |
|
|
| mrbassie wrote: | | To the bark of which tree ought we bark? |
This way. Extra thanks from the user community for also going here.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Sat Jul 22, 2023 6:47 pm Post subject: |
|
|
| Syl20 wrote: |
| Code: | # 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?
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Sat Jul 22, 2023 6:50 pm Post subject: |
|
|
| mrbassie wrote: | | 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.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2014
|
| Posted: Sat Jul 22, 2023 6:54 pm Post subject: |
|
|
| stefan11111 wrote: | | ... What about dhcpcd? |
Or wpa_supplicant and its GUI?
_________________
Greybeard |
|
| Back to top |
|
|
Syl20
l33t
Joined: 04 Aug 2005
Posts: 619
Location: France
|
| Posted: Fri Jul 28, 2023 10:26 am Post subject: |
|
|
| Goverp wrote: | | stefan11111 wrote: | | ... 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. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
