| 1 |
Zac Medico wrote: |
| 2 |
|
| 3 |
> Rémi Cardona wrote: |
| 4 |
>> Zac Medico a écrit : |
| 5 |
>>> Please consider a PROPERTIES=set value that allows an ebuild to |
| 6 |
>>> indicate that it should behave like a package set when selected on |
| 7 |
>>> the command line. This is behavior is somewhat difficult to describe |
| 8 |
>>> in words but the following example should be sufficient to convey |
| 9 |
>>> the general idea. |
| 10 |
>> |
| 11 |
>> As one of the maintainers of the gnome-base/gnome meta, I fail to see |
| 12 |
>> the usefulness of such a change. We have yet to ask users to rebuild |
| 13 |
>> "gnome" completely. Do you have any specific use cases (maybe coming |
| 14 |
>> from the KDE herd, since you used the kde meta as an example) ? |
| 15 |
>> |
| 16 |
>> The one thing that bothers me about this is consistency: if, say, xfce |
| 17 |
>> (let's change ;) ) decides to use PROPERTIES=set, users will have a |
| 18 |
>> different experience with their ebuild than with the other metas we |
| 19 |
>> currently ship. |
| 20 |
>> |
| 21 |
Only when they consciously use the set syntax, surely? |
| 22 |
|
| 23 |
>> All in all, I'm not really against such a change, however I really fail |
| 24 |
>> to see the win for everyone, end-users included. |
| 25 |
> |
| 26 |
> Over the course of the discussion I've revised the idea so that it |
| 27 |
> essentially represents a way to define a package set, without any |
| 28 |
> changes to existing behavior. What will change is that we will have |
| 29 |
> a new way to define package sets, based on ebuilds. |
| 30 |
|
| 31 |
Makes sense to me, though not sure you need the mapping file. I'm perfectly |
| 32 |
happy about emerge -uDN @kde-meta say, updating all kde-meta packages I |
| 33 |
might have installed; I take it that after emerge kde-meta to install, and |
| 34 |
then removing some of the packages, the user could continue to reference |
| 35 |
the set for upgrade, without portage reinstalling those? |
Archives