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

[Steve Long]

Joe Peterson wrote:

> Duncan wrote:
>> That's an interesting idea.  I don't personally care either way, as long
>> as @world continues to /not/ include system/@system, but having world
>> (without the @) continue to include system /would/ be useful for backward
>> compatibility.  I think it'd be much better in terms of ease of educating
>> the vast majority of stable users, as the @ is new anyway, so it can have
>> new behaviour without a problem, but having new behaviour for world does
>> present a significant re-education/retraining issue.

Yeah that was my thinking (only better expressed ;)

> The only drawback I see is that we would then have the following:
>
> @system == system
> ...but...
> @world != world
>
> This, I would think, could cause confusion too - and we'd have to live
> with and document this "quirk".
>
I don't see that as major from a user pov; as soon as you see @ you're in
set territory, which is for finer-grained control. We already expect users
to have the ability to read docs and the like, and this way we're not
introducing any surprises; for the standard update procedure we're all used
to, sets don't come into it.
 
> How about issuing a warning when portage starts if the user specifies
> "world" (with no "@" sign) as the only specified target *and* @system is
> not in world_sets?
>
It's starting to get tricky.. ;)
 
> It would warn that the world set no longer automatically includes system
>  (i.e., @system) and also that it is better, from now on, to explicitly
> use the "@" sign for all sets like world and system (since these two are
> special cases grandfathered in).
>
.. and we still get the issue that future usage would mean needing: 
emerge @world @system # or should it be the other way round?
..when we used to have a simple 'emerge world'[1]. I don't see how that
helps our users. iow the change feels like a loss, not an improvement
(which the set code certainly is), when a little tweaking with the option
parser would mean we had both uses. I see it as polishing the UI, nothing
more.

Maybe there's a case for dropping system as a special-case over time, and
giving a deprecation warning. Personally I don't see the problem with
simply continuing to support it, or even changing to mean system without
any user-defined stuff/ as per-profile; option parsing is hardly the
bottleneck ;)

[1] Assuming user doesn't want @world always including @system, which makes
sense to a power-user who would be interested in sets, as Duncan showed.