-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 03 Jun 2014 09:26:09 -0400 Ian Stakenvicius <a...@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 03/06/14 08:08 AM, Tom Wijsman wrote: > > On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman <ri...@gentoo.org> > > wrote: > > > >> This probably could have used a news item, as the change impacts > >> both stable and ~arch users. > > > > Are we going to write a news item every time systemd acquires a > > new mandatory relationship with a reverse dependency? > > > >> They need to do an "emerge -1 sys-power/upower-pm-utils" to > >> actually get the new package, > > > > But the user doesn't want systemd; so, then why does the user have > > to perform a manual step every time that systemd has an > > acquirement? > > That's easy -- we don't have a way to do vdb updates that will split a > package, only move a package. And since this isn't a package move (as > the original package still exists) we can't leverage that. - From the dependency viewpoint this isn't a package split or move, it is rather an introduction of || ( A B ) "alternatives" in the dependency chain. In this case, the first option (A) is tried and exhausted; this complexity results in other options (B) not being thoroughly considered. If you want Portage to make a transition to alternatives, you need to get a mask in place for the first option; so, we can leverage this: 1. || ( A B ) with A masked causes Portage to install B instead; 2. || ( <A-0.99 B ) with >=A-0.99 masked causes a downgrade to <A-2. So, what misses here is that mask; which you could put in a mix-in. (In this specific case A is upower and B is upower-pm-utils.) > >> otherwise portage is going to try to switch them from udev to > >> systemd, > > > > There is the problem, the user doesn't want systemd; so, why is > > Portage (regardless of a systemd mask) trying to bring it to the > > user anyway? > > > >> since packages like kdelibs list upower first, and portage has no > >> way of knowing that this is a big change. > > > > And this is where you can make Portage smarter. > > > > http://www.funtoo.org/Flavors_and_Mix-ins > > > > We don't have to go through all this if you had a "no-systemd" > > mix-in, where you could simply make out the choices in favor of the > > user instead of having to document and announce them all over the > > place. > > > > That mix-in could do something like masking the new upower that > > depends on systemd; when doing so, no more blockers all over the > > place. > > > > Technically we could do this via a systemd profile too -- ie, mask new > upower everywhere but systemd profiles, and in systemd profile mask > upower-pm-utils. In doing so, you assume that non-systemd profiles are anti-systemd; however, that's not the case. Currently GNOME and KDE have systemd profiles; but, there are a lot of other desktop environments in the Portage tree that have support for systemd. So, this means we would have to go and create a profile for each desktop environment and within such profile yet another profile for systemd; this becomes somewhat tedious if you can cover all that in a mixin instead. You're going to need mixins at some point when it's not just "systemd" that is a specialization but something else as well; unless you want to create even more directories for the possible combinations: - gnome/somethingelse - gnome/systemd - gnome/systemd+somethingelse > However, that doesn't get around the actual need to > - --unmerge upower and emerge upower-pm-utils (or hopefully just do > the latter as a soft-block will do the unmerge?) Portage does this for you if you mask upower and provide it with sufficient backtracking; so, there's no need to do this manually. More explicitly noted: An upower mask allows us to say that an upgrade should do `emerge -C upower` and `emerge upower-pm-utils`, in the case that there is || ( upower upower-pm-utils ) listed as a dependency. Unless you have selected upower on purpose; which would be a different case than the one we're discussing here, also giving different output as it'll point out that @selected brings in what (upower) has been masked. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJTjdWXAAoJEPWZc8roOL/QTwAIAJeYIYpF4JIclsGY67ZHDpuM D2rY3JlCEof4iMcPGccR+lsiTWp0inRRkR5YYejPTMupD/MUqmhuxAogLcUE79m6 lBGQOmO9G4Iduvuoesa99x7UUW6Ihx9TrmoPmn++S9Bn8FrFq+52rUkRDFrlbsrP +wyrc2Dh8SQlI7Bf2r0WcloE9xb+TVXKeyJeZs9eN0afQXqtFJraoGuPYsj7yF7f JWHq26HWRBd+EM8Gyx0OHgPW4Uc7mwhabywxfh44HcjLvh5DN+4/fXbLXc6ytBvi Z5+4UMMXNEUloovKKHT45uVCJ159njFk9KW5SQhKRihaQD63USMm+sKGm0Kx0Ek= =Sugk -----END PGP SIGNATURE-----
