Re: [gentoo-dev] Re: Re: News item: World file handling changes in Portage-2.2
Holger Hoffstaette wrote: On Wed, 10 Sep 2008 11:38:56 +0100, Mike Auty wrote: Marius Mauch wrote: Maybe the best solution is to drop the non-prefixed versions of 'world' and 'system' completely Deprecating the old syntax sounds like a sensible action to get people shifted onto the new system. I imagine it would work very similarly to "emerge info" at the moment? Speaking purely as a user, from a usability perspective it's a horrible idea. Don't make me remember special things. To me there is no discernible difference between "system" and "@system", except that I have to remember to prefix the latter over and over again. Different things need different names. Doesn't portage have more pressing problems? In the last 6 years of using Gentoo I cannot remember a single instance where the difference between system and world even mattered to me from an operational point of view. Holger Also speaking as a user, I confuse pretty easily and you can ask anyone on gentoo-user about that. However, I see the difference between @system and system. The same for world or at least a good idea anyway. I have to also say that I like being able to type in emerge -uvDN world and letting my system upgrade everything that needs upgrading. It's simple, easy and not so much typing. I can somewhat understand the need for @system and @world but think both can live together pretty well. I also can't think of a better name to call it either. I do think there should be some sort of notice for those users that do not follow -dev, -user and/or the forums tho. That has been a issue for a long time. There does not seem to be a clear cut way to inform all Gentoo users except during a emerge. Thing is, emerge -uvDN world will do the same as it always has from my understanding. My $0.02 worth. Dale :-) :-)
[gentoo-dev] Re: Re: News item: World file handling changes in Portage-2.2
On Wed, 10 Sep 2008 11:38:56 +0100, Mike Auty wrote: > Marius Mauch wrote: >> Maybe the best solution is to drop the non-prefixed versions of 'world' >> and 'system' completely > > Deprecating the old syntax sounds like a sensible action to get people > shifted onto the new system. I imagine it would work very similarly to > "emerge info" at the moment? Speaking purely as a user, from a usability perspective it's a horrible idea. Don't make me remember special things. To me there is no discernible difference between "system" and "@system", except that I have to remember to prefix the latter over and over again. Different things need different names. Doesn't portage have more pressing problems? In the last 6 years of using Gentoo I cannot remember a single instance where the difference between system and world even mattered to me from an operational point of view. Holger
[gentoo-dev] Re: Re: News item: World file handling changes in Portage-2.2
Marius Mauch wrote: > On Wed, 10 Sep 2008 01:43:45 +0100 > Steve Long <[EMAIL PROTECTED]> 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.
Re: [gentoo-dev] Re: Re: News item: World file handling changes in Portage-2.2
Steve Long wrote: >> @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. Ah, OK. I have been considering that "world" is simply a grandfathered name for "@world" (and same for system). I.e. that "world" is also specifying the world set, but that only world and system are allowed to have the "@" dropped to avoid breaking things for users. Isn't that the way the code treats it now? Or is "world" (no "@") really not a set? >> 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 just seems like that's the most common case (expecting "world" to include "@system" and "@world"), so if it doesn't, warn the user, and in the process migrate users to using "@" (to avoid the warning). > .. and we still get the issue that future usage would mean needing: > emerge @world @system # or should it be the other way round? True, but as Duncan discovered, if you leave off the -1, @system gets put in world_sets anyway, and some might want that. Then @world includes both. > ..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. I know what you mean. And I'm not sure what makes most sense. It still seems potentially confusing for "world" and "@world" to mean different things. If the words were different, it would not seem that way. > Maybe there's a case for dropping system as a special-case over time, and > giving a deprecation warning. Yeah, I'd vote for that. -Joe
[gentoo-dev] Re: Re: News item: World file handling changes in Portage-2.2
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.
