[gentoo-dev] Re: Re: News item: World file handling changes in Portage-2.2

[Steve Long]

Marius Mauch wrote:

> On Wed, 10 Sep 2008 01:43:45 +0100
> Steve Long <slong@××××××××××××××××××.uk> wrote:
>
>> Marius Mauch wrote:
>>
>> > Second for the suggestions on how to handle the transition:
>> > - treating 'world' and '@world' differently is a no go from my POV.
>> > One of the main reasons to implement them as sets was to remove
>> > special case code in emerge, so I'm quite opposed to adding new
>> > special cases instead. And I'm quite sure that such a separation
>> > would cause confusion, and some isues regarding (end-user)
>> > documentation.
>>
>> We're talking about one special case in the command-line processing,
>> to support the existing usage that all our users are used to. It adds
>> practically nothing in execution time, simply expanding to @system
>> @world, and means that users who don't want to know about sets, or
>> are not thinking in set terms at the time of using emerge, will get
>> the result they expect.
>
> It also means we'd indefinitely have to carry another special
> case around for legacy reasons (removing it later would be even more
> painful than doing the switch now). You know, those are the things we
> want to get rid off, as they really make our life harder in the long
> run. YOu may consider it trivial in this cse, but these things always
> look trivial when you're adding them, and you curse about them when you
> have to modify the code later on.

I know exactly what you mean. However, this special case *will* save Gentoo
a great deal of support hassle, imo at least, and is confined to the
option-parsing code. It's perfectly well encapsulated and will never `leak'
into any of your dependency resolution or set-handling code.

> Maybe the best solution is to drop the non-prefixed versions of 'world'
> and 'system' completely ....

I'm fine with system ;) although as outlined, I don't see that it can add
maintenance to anywhere but the option parser, and only then if what you
want the end-user to update by default changes.

I see that indirection as an added bonus, since it means you can easily
maintain a cli api for end-users (or tired admins) as opposed to
power-users or devs, and the sets [or indeed options] used can change over
time (since we're discussing long-term maintenance) without the same
switchover hassles as now. There'd be zero need to reeducate the end-users,
and interested ones would be following dev, or would read about any new set
in GMN.