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.
