| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Steve Long wrote: |
| 5 |
> Zac Medico wrote: |
| 6 |
> |
| 7 |
>> Rémi Cardona wrote: |
| 8 |
>>> Zac Medico a écrit : |
| 9 |
>>>> Please consider a PROPERTIES=set value that allows an ebuild to |
| 10 |
>>>> indicate that it should behave like a package set when selected on |
| 11 |
>>>> the command line. This is behavior is somewhat difficult to describe |
| 12 |
>>>> in words but the following example should be sufficient to convey |
| 13 |
>>>> the general idea. |
| 14 |
>>> As one of the maintainers of the gnome-base/gnome meta, I fail to see |
| 15 |
>>> the usefulness of such a change. We have yet to ask users to rebuild |
| 16 |
>>> "gnome" completely. Do you have any specific use cases (maybe coming |
| 17 |
>>> from the KDE herd, since you used the kde meta as an example) ? |
| 18 |
>>> |
| 19 |
>>> The one thing that bothers me about this is consistency: if, say, xfce |
| 20 |
>>> (let's change ;) ) decides to use PROPERTIES=set, users will have a |
| 21 |
>>> different experience with their ebuild than with the other metas we |
| 22 |
>>> currently ship. |
| 23 |
>>> |
| 24 |
> Only when they consciously use the set syntax, surely? |
| 25 |
|
| 26 |
Right. |
| 27 |
|
| 28 |
>>> All in all, I'm not really against such a change, however I really fail |
| 29 |
>>> to see the win for everyone, end-users included. |
| 30 |
>> Over the course of the discussion I've revised the idea so that it |
| 31 |
>> essentially represents a way to define a package set, without any |
| 32 |
>> changes to existing behavior. What will change is that we will have |
| 33 |
>> a new way to define package sets, based on ebuilds. |
| 34 |
> |
| 35 |
> Makes sense to me, though not sure you need the mapping file. I'm perfectly |
| 36 |
> happy about emerge -uDN @kde-meta say, updating all kde-meta packages I |
| 37 |
> might have installed; I take it that after emerge kde-meta to install, and |
| 38 |
> then removing some of the packages, the user could continue to reference |
| 39 |
> the set for upgrade, without portage reinstalling those? |
| 40 |
|
| 41 |
That would be a set subtraction operation, so the user would use a |
| 42 |
configuration file to configure the set so that certain unwanted |
| 43 |
atoms are automatically subtracted out. Alternatively, we could |
| 44 |
implement a syntax extension for "optional atoms" that are only |
| 45 |
pulled into the dependency graph if they happen to be installed already. |
| 46 |
|
| 47 |
- -- |
| 48 |
Thanks, |
| 49 |
Zac |
| 50 |
-----BEGIN PGP SIGNATURE----- |
| 51 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 52 |
|
| 53 |
iEYEARECAAYFAkjhOnQACgkQ/ejvha5XGaMj1QCfRzl74HWG/s4nuf7pqIiZ8sEt |
| 54 |
77IAn18mFmdmc3JCOJil2S1NPJcEe1wX |
| 55 |
=M2k9 |
| 56 |
-----END PGP SIGNATURE----- |
Archives