Bug#401317: RELEASE NOTE (suggestion)
Hi,
I thought my suggestion was just a reminder to something everyone agree
once you do upgrade of desktop system onself. Hmmm... I will add this
discussion to my old report on this issue as a record.
http://bugs.debian.org/401317
Back then Frans said he needed to use interactive session to upgrade
desktop system.
Steve, your technical assessment itself on possible concerns for pulling
tasksel is quite right as usual :) But I think I did not communicated my
concern well.
I am not quite sure how exactly current aptitude displays task list. It
looks like aptitude uses /usr/share/tasksel/debian-tasks.desc to
establish package list which each task pulls in.
This /usr/share/tasksel/debian-tasks.desc used to be in task package but
now moved to tasksel-data package. Somehow these 2 packages "Depends:"
on each other. If there is no "Depends: tasksel" in tasksel-data,
installing tasksel-data is the almost no liability action to get
aptitude with correct task list. But under current situation, it pulls
in tasksel and causes concerns Steve raised.
Let me comment as follows.
On Sat, Jan 20, 2007 at 02:16:00AM -0800, Steve Langasek wrote:
> 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?
To get reasonably looking task list.
> > 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. :)
Correct. What is really needed is tasksel-data as I mentioned as above.
> > 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?
As I tested before in 401317, when complication happens with desktop
task, the easiest way for me was to remove (but not purge) all desktop
packages from the aptitude task menu and update the smaller system.
Then installed the desktop relying on the task list. For that, I needed
tasksel-data and for me typing tasksel was the shortest name. (Due to
mutual dependency, it did not make any difference using tasksel or
tasksel-data)
Since I did not use perl upgrade trick as described, my concern may have
been just worry. I will revisit this when I find my time.
Osamu
Reply to: