[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RELEASE NOTE (suggestion)



Hi Osamu,

On Mon, Jan 15, 2007 at 11:12:48PM +0900, Osamu Aoki wrote:
> On Mon, Jan 15, 2007 at 02:42:20AM -0800, Steve Langasek wrote:
> > On Mon, Jan 15, 2007 at 03:07:30AM +0900, Osamu Aoki wrote:

> > > In 4.4.2 Upgrading aptitude

> > > You only updating aptitude.

> > > I think updating tasksel (hence tasksel-data) together will make less
> > > surprise.  (Proper Desktop task list ...)

> > > -     # aptitude install aptitude
> > > +     # aptitude install aptitude tasksel

> > Why would it be important to install tasksel before dist-upgrading?  tasksel
> > isn't called directly in the upgrade process, and I don't think aptitude
> > dist-upgrade looks at tasks either, does it?

> I do not think I said "important".  I just *suggested* this since I
> thought it is a *good* idea to "make less surprise" under unpredictable
> upgrade breakage.  I mean this is zero liability action with reduction
> of possible negative situation.

The liability is:

- Some users will not have tasksel installed on their system.  Telling them
  to run aptitude install aptitude tasksel will install a package that they
  don't need or want.
- Some users will know that they don't want tasksel installed, and ignore
  these instructions.  That increases the number of upgrade paths that we
  need to support.
- tasksel has dependencies that wouldn't otherwise need to be pulled in at
  this early stage -- in particular, a newer version of debconf than shipped
  with sarge.  This makes the first stage of the upgrade more complex, and
  therefore increases the risk of bugs.  We want this part of the upgrade to
  be simple.
- If something does go wrong, novice users will have a harder time
  understanding what happened because of the larger number of packages
  involved.

So yes, there needs to be an important reason that outweighs these
liabilities. :)

> Here is a bit more explanation.  As stated in 4.4.2, "In some cases if a
> large number of packages is listed for removal", this is what I fear.
> Of course if your KDE fix trick closes the gap completely and "aptitude
> -f --with-recommends dist-upgrade" nicely upgrade system without
> interactive work, my fear may be non-significant one. 

> But an user may have installed some funny set of non-desktop programs
> which we did not tested (tetex?) and it may create problem.  Current
> aptitude as released for etch will have important and difficult to fix
> bug before release for dist-upgrade.  

> See http://bugs.debian.org/391377 .  

> Whoever hits such a bug will try to resolve it relying on aptitude's
> interactive mode to solve situation.  If we do not update tasksel-data,
> the menu under tasks does not seem to have reasonable appearance for
> desktop task etc.  So we can focus on addressing real issue.

So your concern is that users will try to resolve this dist-upgrade
interactively, rather than choosing one of the solutions from the
commandline interface, and that in the process they'll use the task list?  I
suppose this is possible, but a) I don't see how the task list is relevant
to resolving a dist-upgrade problem, b) using aptitude interactively is
already not part of the documented, recommended upgrade procedure, right?

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Reply to: