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.
