in trying to install snapd I came to the conclusion that the ebuild is bugged because it REQUIRES ALL OF IT'S USE FLAGS to be set. I tried disabling everything to get a bare build because it was trying to install systemd and I don't use systemd. But when the systemd use flag was disabled, portage stated that required USE flags were not set, and stated EACH FLAG that I had disabled as required.
I guess what the ebuild is trying to tell you is that snapd really really needs systemd. Why do you think that is wrong?
And it doesn't ignore the other use flags, you just need to read the constraints correctly. I can't show you nice output for lack of a systemd box here, but it is how it is.
Both ebuilds in the repo have REQUIRED_USE="!forced-devmode? ( apparmor cgroup-hybrid ) systemd" which looks rather suspicious I'd say. How is one supposed to fullfill this without systemd?
Precisely what Polynomial-C said. Not everyone likes Systemd. I've helped two people setup Gentoo in the past month and both said one requirement was “NO SYSTEMD”. So, for them, snapd is a no-go because it seems to REQUIRE Systemd. There should never be a package that REQUIRES either OpenRC or Systemd unless it's an option component of those very items. I.e., it makes perfect sense to say systemd-cron can only be installed with Systemd because it's INTENDED to go with Systemd. But a program that has nothing in relation to either one (which snapd doesn't) should never insist on one or the other.
When I was working on the ebuild I got the impression that systemd was a hard requirement, but I'm happy to accept patches if you can make it work without systemd.
After doing some heavy searching myself, it looks like systemd is a pretty strict requirement, mainly because the devs who wrote it decided to take advantage of shortcuts offered by systemd. I've seen plenty of discussion that says it COULD be ported to work with OpenRC, but that the devs don't want to go through the hassle. So I guess this can be closed as either NOTABUG or WONTFIX. Still, it's very disappointing!
What confuses me about the ebuild is the REQUIRED_USE line: REQUIRED_USE="!forced-devmode? ( apparmor cgroup-hybrid ) systemd" This looks like the intention was something like: If you do not enable forced-devmode, you need either apparmor or cgroup-hybrid and in addition systemd. So in reverse it would imply that with forced-devmode enabled you would need neither of those. If systemd is a hard requirement, i dont see a point in having a useflag for it, which is then forced to be enabled. In thise case a required dependency should just be included in the depencency list without any USE flag.
(In reply to Thomas Sachau from comment #7) > What confuses me about the ebuild is the REQUIRED_USE line: > > REQUIRED_USE="!forced-devmode? ( apparmor cgroup-hybrid ) systemd" > > This looks like the intention was something like: > > If you do not enable forced-devmode, you need either apparmor or > cgroup-hybrid and in addition systemd. So in reverse it would imply that > with forced-devmode enabled you would need neither of those. > > If systemd is a hard requirement, i dont see a point in having a useflag for > it, which is then forced to be enabled. In thise case a required dependency > should just be included in the depencency list without any USE flag. Doesn't the USE flag make it easier for people to recognize that the systemd dependency is unconditional? I imagine that if the systemd USE flag does not exists, then it will encourage people to hunt for ways to eliminate it (fruitlessly).
(In reply to Zac Medico from comment #8) > (In reply to Thomas Sachau from comment #7) > > What confuses me about the ebuild is the REQUIRED_USE line: > > > > REQUIRED_USE="!forced-devmode? ( apparmor cgroup-hybrid ) systemd" > > > > This looks like the intention was something like: > > > > If you do not enable forced-devmode, you need either apparmor or > > cgroup-hybrid and in addition systemd. So in reverse it would imply that > > with forced-devmode enabled you would need neither of those. > > > > If systemd is a hard requirement, i dont see a point in having a useflag for > > it, which is then forced to be enabled. In thise case a required dependency > > should just be included in the depencency list without any USE flag. > > Doesn't the USE flag make it easier for people to recognize that the systemd > dependency is unconditional? I imagine that if the systemd USE flag does not > exists, then it will encourage people to hunt for ways to eliminate it > (fruitlessly). We want to avoid questions of this sort: I've disabled the systemd USE flag, so why is emerge trying to install systemd?
(In reply to Zac Medico from comment #8) > Doesn't the USE flag make it easier for people to recognize that the systemd > dependency is unconditional? I imagine that if the systemd USE flag does not > exists, then it will encourage people to hunt for ways to eliminate it > (fruitlessly). To me, it implies the exact opposite. Isn't the very existence of a USE flag supposed to imply that something is optional? > We want to avoid questions of this sort: > > I've disabled the systemd USE flag, so why is emerge trying to install systemd? That is a good point, though. Is it possible to make it a forced flag or something? Or mask it out for non-Systemd profiles? At least unless/until Systemd is no longer required?
(In reply to Daniel Dawson from comment #10) > Or mask it out for non-Systemd profiles? Er, mask the package, I mean.
the reason is explained here (though not sure it's up to date, i just searched how to avoid systemd too): https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd
From USE official documentation: > The idea behind USE flags > When installing Gentoo, users make choices depending on the environment they are working with. A setup for a server differs from a setup for a workstation. A gaming workstation differs from a 3D rendering workstation. It says a choice users make, and not developers or maintainers. > This is not only true for choosing what packages to install, but also what features a certain package should support. If there is no need for OpenGL, why would someone bother to install and maintain OpenGL and build OpenGL support in most of the packages? If someone doesn't want to use KDE, why would they bother compiling packages with KDE support if those packages work flawlessly without? This emphasizes on using USE as features, and not requirements. > To help users in deciding what to install/activate and what not, Gentoo wanted the user to specify his/her environment in an easy way. This forces the user into deciding what they really want and eases the process for Portage to make useful decisions. Again, it's about users' decisions. These three paragraphs are the whole "The idea behind USE flags" from handbook guide, I didn't filter it just to support my point: https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/USE Having developed software on top of systemd, I understand how developers might not like to implement and support another limited and hacky init system, but applying these requirements by the means of USE, seemed confusing to me and against the ideas behind USE, as mentioned above.
