Bug#506406: [Pkg-xfce-devel] Bug#506406: xfce4: apt bug causes gdm to pull in unneeded/unwanted gnome dependencies
On Wednesday 07 January 2009, Daniel Dickinson wrote:
> 1) Install a standard system (say from netboot, netinst, or because you
> only have regular CD #1 not the xfce CD #1)
You can also very easily install alternative desktop environments using
the buisinesscard or netinst CDs, or DVDs. See the recent "Bits from the
Debian CD team" on d-devel-announce.
If you know you will be using a network mirror you can even select the
correct desktop task with the regular CD by adding 'desktop=xfce' as boot
parameter. The same works for netboot and hd-media installs.
> 2) You want xfce installed, now what?
> 2a) Using aptitude interactively by select Task|Xfce Desktop
> gnome-session is pulled in along with nautilus and other gnome
Note that you need to select both the xfce-desktop _and_ the desktop task
if you do the install from inside aptitude's frontend.
> 2a.1) you can avoid some of this if you know that you need to say
This is a general difference between new installs and using aptitude
interactively. For installing tasks I would always suggest not selecting
> 2a.2) To avoid gnome-session (which is pulled in by gdm) you have to
> manually deselect it (and know that it's there, rather than being
> surprised by it later as I was - in my case because my $HOME had
> originally been used for GNOME and was later converted to XFCE when I
> did a reinstall I had a system that wouldn't start the desktop because
> gnome-session instead of xfce-session was starting)
You can also, instead of selecting the whole task, select the individual
packages belonging to the task. If you do that in the correct order (xfce
packages before gdm), you can avoid gnome-session.
This use-case (selecting xfce-desktop or lxde-desktop tasks using the
aptitude frontend) is the only reason why switching gdm to xdm could
still be considered.
I expect that it would improve the user-friendliness of installing the
tasks by reducing the number of dependencies that get pulled in
unexpected/unwanted, but this cannot be tested other than by doing an
actual upload of tasksel.
However, I agree with Corsac that that's not the primairy use-case for
tasks and so leaving things as they are for Lenny is a valid choice.
> 2b) aptitude from the command-line:
> I haven't tried this yet because I didn't know about it; presumably
> using tasks like tasksel -t emits will work
I have tested this and it does work correctly; it just pulls in the
minimal GNOME packages that are the result of gdm being included.
In my tests gnome-session or nautilus etc did not get installed.
> 2c) apt-get from the command-line:
> Suffers from the same problem as 2a unless you make sure that
> xfce4-session is *before* gdm. It's also not as easy because you need
> to know that packages you want installed
AFAIK apt-get does not know about tasks, so basically you're just
installing some random selection of packages.
> 2d) tasksel
> * Need to set tasksel/desktop to xfce
> * Don't know if it'll work correctly or not given Frans statement that
> tasksel isn't meant to be used this way.
Well, it is meant to be used this way, and it does work if done correctly.
But doing it correctly for desktop tasks other then GNOME is very much
not trivial ATM.
The correct way using tasksel is:
1) ensure that tasksel/desktop is set correctly
2a) run 'tasksel' OR
2b) run 'tasksel --install desktop'
> Maybe Frans can suggest something about tasksel that would make this
I've added some comments to #510928.
> aptitude has a bug
The main bug in aptitude is that when a task is selected in the aptitude
frontend, alternative dependencies are not handled correctly: if an
alternative dependency is satisfied by a package in the task, aptitude
should not also be selecting the primairy alternative.
Example: 'AAA depends XXX | YYY' and 'BBB depends YYY'. If AAA and BBB are
both in the task, then only YYY should be selected. Currently aptitude
_may_ also select XXX, presumably if AAA is processed before BBB.
Another bug in aptitude is that it *only* considers tasks definitions from
the Packages file (based on Task: fields).
AFAICT it does read /usr/share/tasksel/debian-tasks.desc, but seems to
ignore the possibility that the task may define the packages belonging to
the task as a list inside that file itself instead of using Packages.
> taskel doesn't support xfce as a desktop choice unless you use the xfce
> cd, which is a bug IMO
That is not correct. It does support it, but not in an obvious and
> Frans: would that work? How difficult is adding a debconf question for
> the desktop (which would default to gnome in d-i?)
That is not an acceptable solution. The only real option here is some
fundamental redesign of tasksel.
> Frans: also are you the one to talk to about tasksel?
No, not really. And I think I'm going to make this my last post to this