Package: partman-target
Severity: normal

This bug occurs in the debian-edu version of the sarge installer, which
reorders the main menu so autopartkit comes before partman. On such a
system, main-menu skips over autopartkit, which is first, and selects
partman. But if partman is not included on the CD, then it happily
selects autopartkit.

Currently debian-edu-profile-udeb has a menu item of 17;
debian-edu-install-udeb is 10 and depends on it, autopartkit, 
bootable-system, and prebaseconfig. This makes main-menu order the menu
as follows:

languagechooser                 10
kbd-chooser                     12
debian-edu-profile-udeb         17
hw-detect-full                  35
autopartkit                     50
partman                         42
base-installer                  65
grub-installer                  73
prebaseconfig                   78
debian-edu-install-udeb         10
country-chooser                 11
cdrom-detect                    14
load-cdrom                      14
lilo-installer                  75

main-menu goes down this list and will run the first item that isn't
configured whose memu-item-number is greater than 14 (the number of
load-cdrom, which was the last menu item run). That is
debian-edu-profile-udeb. After the profile is selected, it advances to
hw-detect-full which is next. After that, we'd expect it would go to
autopartkit.

It skips autopartkit because provides_installed_virtual_package()
returns true for that package. This is supposed to mean that autopartkit
provides a virtual package that is also provided by some other already
configured package. AIUI, this check takes care of skipping
lilo-installer after grub-installer has been run.

The problem is that autopartkit provides created-fstab, and so does
partman-target. So main-menu skips autopartkit. I think the problem is
that partman-target is not a menu item, but provides something also
provided by a menu item; worse it provides something that is not
satisfied when partman-target is configured, but only after partman
runs. So this provide belongs in partman.

Now, maybe main-menu should only consider menu items for this test (but
it seems hard to make this change to provides_installed_virtual_package.
Another way to look at it is that autopartkit provides several things
that are not yet also provided by configured packages, perhaps it should
only be skipped if all its provides are otherwise satisfied. That is
easy to implement, but I haven't done it because who knows what it might
break.

A few recent changes consipired to expose this bug:

 - anna was changed to configure packages that are not menu items as
   it loads them; previously they were marked as unpacked and not
   configured and so did't trigger the check
 - partman-target and autopartkit began to provide created-fstab,
   previously partconf-mksftab did this.

-- 
see shy jo

Attachment: signature.asc
Description: Digital signature

Reply via email to