On Wed, 4 Jun 2014 01:06:52 +0300 Alon Bar-Lev <alo...@gentoo.org> wrote:
> Once again, you do not understand the claim. > > If a user of Gentoo chooses to use non systemd profile, it means that > we need to make sure systemd will not be a valid option, ever. There is no such thing as a "non systemd profile" on Gentoo at the moment; you have ".../systemd" profiles, which are specializations of the more generic case "..." which you can fill in with "gnome" or "kde". So, I'm here running this agnostic MATE with a make.profile symlink that doesn't point to a ".../systemd" profile; what is remarkable, is that systemd is a valid option in this case. Similarly, if I pick a ".../systemd" profile; what is remarkable, is that OpenRC is also a valid option in that case. For there to be a "make sure systemd will not be a valid option, ever" there would have to be a ".../no-systemd" profile or something like that; in such profile, one could then mask anything that tries to pull in systemd and not have to deal with further transitions later on. Splitting up profiles this way becomes a pain to maintain; other than that, it is also a controversial way to go about it given that a "no-..." type of profile hasn't been commonly used before yet. In this train of thoughts Funtoo mix-ins could help to do it more clean. http://www.funtoo.org/Flavors_and_Mix-ins But until we've got something, we've got to accept that other options remain valid choices; profiles are just there, well, to ensure a particular choice is properly supported without further implications. > In this case, if it is to disable the upower USE flag, or to provide > alternative, block newer version, whatever make it possible to have a > system working without systemd. > > systemd should not be visible at any time, nor its implications. > > Alon It is easy to make such a statement, but it is hard to make it happen; upstreams change over time, which makes such implications happen sooner or later in one place or the other. Which becomes visible over time... The manpower that we have to keep implications away are limited; to make a change to those implications, one could write code as suggested. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
