--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: tasksel: fails to preseed desktop on kfreebsd, hurd
- From: Steven Chamberlain <steven@pyro.eu.org>
- Date: Sat, 15 Nov 2014 02:20:53 +0000
- Message-id: <20141115022053.63520.58836.reportbug@sid.kfreebsd-amd64.pyro.eu.org>
Package: src:tasksel
Version: 3.29
Severity: important
Hi,
(this bug may also affect linux release architectures other than
i386|amd64|powerpc*, and their CD media, so severity may be higher)
It was seen on kfreebsd and hurd that preseeding with:
tasksel tasksel/first multiselect standard, desktop
tasksel tasksel/desktop multiselect xfce
no longer works, a regressions since wheezy; no desktop gets installed:
https://lists.debian.org/debian-hurd/2014/11/msg00074.html
The logic gets ridiculously complex, but I gather that:
* tasksel/first item "desktop", used to be the only thing listed;
selecting or preseeding it would previously install task-desktop
as well as task-xfce-desktop (whatever was default, or preseeded as
tasksel/desktop)
* now, preseeding tasksel/desktop seems to work *only* if
/usr/lib/tasksel/tests/desktop decides it should install a desktop;
irrespective of whether tasksel/first includes "desktop"
* as such, on kfreebsd, hurd and some other arches, selecting or
preseeding tasksel/first with "desktop" only leads to task-desktop
being installed (the parent item), but not the individual task for
desktop, despite setting tasksel/desktop
So I think possible ways to fix this are:
1. simply adding kfreebsd-* and hurd-* to the list of "common
desktop architectures" may inadvertently fix this - that determines
whether tasksel preselects the 'desktop' option by default;
currently the list has only (linux-) i386|amd64|powerpc* and may
explain why the bug wasn't noticed there
2. make tests/default-desktop not conditional on check_desktop_wanted,
if tasksel/first has "desktop", or tasksel/desktop is preseeded
3. make tests/desktop (whether to install a desktop) answer "yes"
(exit 2) if tasksel/first has "desktop", or tasksel/desktop is
preseeded, overriding any guess it would make based on architecture,
diskspace, RAM etc. that it does currently
I'll send a patch for consideration that probably does all three in
some way.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
- To: Holger Wansing <hwansing@mailbox.org>
- Cc: 769616-done@bugs.debian.org, Steven Chamberlain <steven@pyro.eu.org>
- Subject: Re: tasksel: fails to preseed desktop on kfreebsd, hurd
- From: Samuel Thibault <sthibault@debian.org>
- Date: Sun, 21 Oct 2018 21:07:16 +0200
- Message-id: <20181021190716.nnh2t3wnovuj3nuk@function>
- In-reply-to: <20180930210616.68a49bc8355f0b40b7fde0e3@mailbox.org>
- References: <20180930210616.68a49bc8355f0b40b7fde0e3@mailbox.org>
Hello,
Holger Wansing, le dim. 30 sept. 2018 21:06:16 +0200, a ecrit:
> > Steven Chamberlain, le Sun 10 May 2015 22:41:57 +0100, a écrit :
> > > Samuel Thibault wrote:
> > > > I believe it's completely fixed by now: using
> > > >
> > > > tasksel tasksel/first multiselect standard, xfce-desktop
> > > >
> > > > works to preseed the desktop on !linux, and the tasksel/desktop
> > > > preseeding works as expected.
> > >
> > > The same is also true on linux jessie and sid.
> >
> > I just meant that it used to be disfunctional for !linux before, and the
> > arch difference was fixed in time for jessie.
> >
> > > This preseeds to install XFCE:
> > >
> > > tasksel tasksel/first multiselect standard, xfce-desktop
> > >
> > > whereas this (traditional way) no longer does anything, and you would
> > > still get GNOME or whatever is default:
> > >
> > > tasksel tasksel/desktop multiselect xfce
> >
> > Right, the latter doesn't seem to be propagated to the former when only
> > the latter is preseeded.
>
> What's the status here? Can we close this bug?
I'd say so, thus closing it.
Samuel
--- End Message ---