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

Bug#247927: in debian-edu, main-menu skips over autopartkit to partman due to bad provide

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

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

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 to: