| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 03/06/14 08:08 AM, Tom Wijsman wrote: |
| 5 |
> On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman <rich0@g.o> |
| 6 |
> wrote: |
| 7 |
> |
| 8 |
>> This probably could have used a news item, as the change impacts |
| 9 |
>> both stable and ~arch users. |
| 10 |
> |
| 11 |
> Are we going to write a news item every time systemd acquires a |
| 12 |
> new mandatory relationship with a reverse dependency? |
| 13 |
> |
| 14 |
>> They need to do an "emerge -1 sys-power/upower-pm-utils" to |
| 15 |
>> actually get the new package, |
| 16 |
> |
| 17 |
> But the user doesn't want systemd; so, then why does the user have |
| 18 |
> to perform a manual step every time that systemd has an |
| 19 |
> acquirement? |
| 20 |
|
| 21 |
|
| 22 |
That's easy -- we don't have a way to do vdb updates that will split a |
| 23 |
package, only move a package. And since this isn't a package move (as |
| 24 |
the original package still exists) we can't leverage that. |
| 25 |
|
| 26 |
> |
| 27 |
>> otherwise portage is going to try to switch them from udev to |
| 28 |
>> systemd, |
| 29 |
> |
| 30 |
> There is the problem, the user doesn't want systemd; so, why is |
| 31 |
> Portage (regardless of a systemd mask) trying to bring it to the |
| 32 |
> user anyway? |
| 33 |
> |
| 34 |
>> since packages like kdelibs list upower first, and portage has no |
| 35 |
>> way of knowing that this is a big change. |
| 36 |
> |
| 37 |
> And this is where you can make Portage smarter. |
| 38 |
> |
| 39 |
> http://www.funtoo.org/Flavors_and_Mix-ins |
| 40 |
> |
| 41 |
> We don't have to go through all this if you had a "no-systemd" |
| 42 |
> mix-in, where you could simply make out the choices in favor of the |
| 43 |
> user instead of having to document and announce them all over the |
| 44 |
> place. |
| 45 |
> |
| 46 |
> That mix-in could do something like masking the new upower that |
| 47 |
> depends on systemd; when doing so, no more blockers all over the |
| 48 |
> place. |
| 49 |
> |
| 50 |
|
| 51 |
Technically we could do this via a systemd profile too -- ie, mask new |
| 52 |
upower everywhere but systemd profiles, and in systemd profile mask |
| 53 |
upower-pm-utils. However, that doesn't get around the actual need to |
| 54 |
- --unmerge upower and emerge upower-pm-utils (or hopefully just do the |
| 55 |
latter as a soft-block will do the unmerge?) |
| 56 |
|
| 57 |
|
| 58 |
|
| 59 |
-----BEGIN PGP SIGNATURE----- |
| 60 |
Version: GnuPG v2.0.22 (GNU/Linux) |
| 61 |
|
| 62 |
iF4EAREIAAYFAlONzPEACgkQ2ugaI38ACPDI5AD/eEbk4156UrMNHmCPIA+xwNfe |
| 63 |
nlGC5pnZ3Zs0gu/88EAA/A9hNlNfGzhqorE+8cEz3lkTVuxxq8gv++7Ogm0zY8DU |
| 64 |
=I7Mw |
| 65 |
-----END PGP SIGNATURE----- |
Archives