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) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
