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

Bug#450777: tasksel: Tasksel uninstalls packages without asking



Package: tasksel
Severity: important

Version of the tasksel package: 2.66

Yesterday a new server (dhcp, samba, nis+nfs, cups, ntp) was set up (a
fresh etch install) and has already replaced our old server.

Today I noticed that "at" was not installed somehow. Having never really
used tasksel (it wasn't run during installation, iirc), I started it to
see if there was some kind of basic or minimal (standard) task of
packages.

Tasksel had "Print Server", "File Server", and "Mail server" selected.
Since there was no such task that I was looking for, I deselected the
above and chose "manual package selection" instead. Pressing <OK>
immediately (without any question being asked) lead to the following
actions:

 - Removal of exim4, nfs-kernel-server, cupsys, samba and lots of other
   (less important) packages.

   And yes, the machine in question is our main fileserver. Fortunately,
   nobody's working during the weekend.

 - Installation of nullmailer as MTA.

I would never have expected this. Tasksel does only have an <OK> button
at the bottom of the menu, and without a <cancel> button I would at
least have expected to be asked for confirmation.

I am setting the severity of this bug to important. I would have given
it a higher severity, but since I couldn't find the bug in the archive
nobody else seem to have hit it. So I am assuming that I must have done
something stupid. Still, I don't see from the above what it was.

Hm. Having repaired the damage, I am running tasksel -t now. The
pre-selected set of tasks seems to be matching the currently installed
package selection. Not changing it leads to no action. I had expected
these to be pre-defined tasks which would lead to a different (bigger)
set of packages being installed. This is why I deselected them. And I
expected "manual package selection" to use the currently installed
package set as a base and just start aptitude.

These assumptions were obviously wrong. I don't know the reasoning
behind tasksel's behaviour. But *this* came as a real surprise to me.

BTW, running tasksel -t and deselecting the selected tasks prints the
following output:

Use of uninitialized value in concatenation (.) or string at
/usr/bin/tasksel line 345.
Use of uninitialized value in concatenation (.) or string at
/usr/bin/tasksel line 345.
Use of uninitialized value in concatenation (.) or string at
/usr/bin/tasksel line 345.
aptitude -y remove printconf hpijs foomatic-db-gutenprint cupsys-bsd
foomatic-filters-ppds hplip foomatic-db-hpijs cupsys cupsys-client
cupsys-driver-gutenprint foomatic-db-engine smbfs netatalk smbclient
swat samba-doc winbind samba nfs-kernel-server procmail qpopper
spamassassin exim4 sa-exim mailagent exim4-daemon-light mutt mailx
exim4-config uw-imapd
Use of uninitialized value in concatenation (.) or string at
/usr/bin/tasksel line 345.
Use of uninitialized value in concatenation (.) or string at
/usr/bin/tasksel line 345.
Use of uninitialized value in concatenation (.) or string at
/usr/bin/tasksel line 345.
aptitude

So, "manual package selection" results in aptitude being run
interactively only *after* the previous task changes have been
performed. So no kind of "integrated" process here, where the task
selection leads to different sets of pre-selected packages in the
interactive aptitude.

Does the current version in testing or unstable still behave like this?

Still recovering,
 Nis

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.21.3
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)




Reply to: