Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



On Tue, 03 Jun 2014 09:26:09 -0400

Ian Stakenvicius <axs@g.o> 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 <rich0@g.o>
> > 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  : TomWij@g.o

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-----