USE="multislot" emerge =sys-boot/grub-1.98 failed installing grub2 into proper slot 2. Both 0.97 and 1.98 were installed into same slot 0. It is surprise to me, because now I'm not really sure if this is only my system problem or it is more common problem. ... ./lib64/grub/i386-pc/cdboot.img ./lib64/grub/i386-pc/boot.img >>> Done. >>> Installing (1 of 1) sys-boot/grub-1.98 * QA Notice: Expected SLOT='0', got '2' * checking 240 files for package collisions * * To avoid automounting and auto(un)installing with /boot, ... Just after I added line 'EAPI="2"' into ebuild file, grub2 was installed into proper slot 2. I believe that grub-9999 is affected too by the same problem, but now (20101108) I'm unable confirm this because another upstream bug preventing building grub. This upstream bug was not filed by me (because it is bug in devs tree, not in stable), only mentioned in unrelated #343293.
By adding the EAPI line you forced Portage to regenerate the cache for the ebuild. AFAIK this has nothing to do with EAPI version but with the invariance rules.
Please post your full build log as the extract you pasted only lists the QA warning and no error.
Created attachment 253635 [details] bzip2ed console output I tried first LC_ALL="POSIX" ebuild /usr/portage/ebuilds/sys-boot/grub/grub-1.98.ebuild clean compile install qmerge, but produced build.log was incomplete. Therefore I decided upload text from console. Because full text has size ~1.7 MiB bz2 was uploaded.
eix output after new ebuild 1.98-r1 creation and before eix-update: $ eix sys-boot/grub [UD] sys-boot/grub Available versions: *0.92-r1 0.94-r1 0.96-r1 0.96-r2 (~)0.96-r3 (~)0.97 0.97-r2 0.97-r3 0.97-r4 0.97-r5 0.97-r6 (~)0.97-r8 0.97-r9 0.97-r10{tbz2} (**)1.98{tbz2} (**)9999 {custom-cflags debug multislot ncurses netboot static truetype} Installed versions: 0.97-r10{tbz2}(10:49:44 8.11.2010)(ncurses -custom-cflags -netboot -static) 1.98-r1(2){tbz2}[1](11:13:44 8.11.2010)(multislot truetype -custom-cflags -debug -static Message indicate that grub-1.98 has proper "SLOT 2", but after eix-update: $ eix sys-boot/grub [U] sys-boot/grub Available versions: *0.92-r1 0.94-r1 0.96-r1 0.96-r2 (~)0.96-r3 (~)0.97 0.97-r2 0.97-r3 0.97-r4 0.97-r5 0.97-r6 (~)0.97-r8 0.97-r9 0.97-r10{tbz2} (**)1.98{tbz2} (**)1.98-r1{tbz2}[1] **9999 **9999-r1[1] {custom-cflags debug multislot ncurses netboot static truetype} Installed versions: 0.97-r10{tbz2}(10:49:44 8.11.2010)(ncurses -custom-cflags -netboot -static) 1.98-r1{tbz2}[1](14:48:30 8.11.2010)(multislot truetype -custom-cflags -debug -static) Homepage: http://www.gnu.org/software/grub/ Description: GNU GRUB 2 boot loader Slot 2 sign dissapeared from report. It seems like 'eix' has some problem with conditional SLOTs concept (maybe). Or maybe it is sign of completely different problem. Who known?
There's no error in the attached log. I suspect your original problem was a FILE COLLISION as reported in other bug reports.
(In reply to comment #5) > There's no error in the attached log. > I suspect your original problem was a FILE COLLISION as reported in other bug > reports. > I had no file collision! I just spotted message "QA Notice: Expected SLOT='0', got '2'" on screen. Line 5195 in attached log: 5191 ./lib64/grub/i386-pc/boot.img 5192 >>> Done. 5193 5194 >>> Installing (1 of 1) sys-boot/grub-1.98 5195 * QA Notice: Expected SLOT='0', got '2' 5196 5197 * checking 240 files for package collisions 5198 * 5199 * To avoid automounting and auto(un)installing with /boot, 5200 * just export the DONT_MOUNT_BOOT variable. And because 'eix' displayed line: "Installed versions: 0.97-r10{tbz2}(10:49:44 8.11.2010)(ncurses -custom-cflags -netboot -static) 1.98{tbz2}[1](14:48:30 8.11.2010)(multislot truetype -custom-cflags -debug -static)" my logical conclusion at that time was, that there is some problem with proper slotting. Not with files, because grub-install from grub2 packages was correctly renamed to grub2-install => no file collision, but in some emerge database or elsewhere. I don't know how and where are stored infos about actual packages SLOTs, but 'eix' doesn't display correct info about grub-1.98 as i wrote in my previous comment #4. So I don't know if problem is in conditional SLOTing in grub-1.98 ebuild, 'eix' lack of understanding of this conditional SLOTing or elsewhere. It looks like grub-1.98 was properly slotted but other parts of system, don't understand it. But because this "QA Notice: Expected SLOT='0', got '2'" I'm not sure at all.
(In reply to comment #6) > (In reply to comment #5) > > There's no error in the attached log. > > I suspect your original problem was a FILE COLLISION as reported in other bug > > reports. > > > I had no file collision! > I just spotted message "QA Notice: Expected SLOT='0', got '2'" on screen. Line > 5195 in attached log: > > I don't know how and where are stored infos about actual packages SLOTs, but > 'eix' doesn't display correct info about grub-1.98 as i wrote in my previous > comment #4. So I don't know if problem is in conditional SLOTing in grub-1.98 > ebuild, 'eix' lack of understanding of this conditional SLOTing or elsewhere. > > It looks like grub-1.98 was properly slotted but other parts of system, don't > understand it. But because this "QA Notice: Expected SLOT='0', got '2'" I'm not > sure at all. There is an error with the SLOT but that won't break the merge of the package. The slot problem is caused by the following in the ebuild: use multislot && SLOT="2" || SLOT="0" This breaks the invariance rule that state that the SLOT must be a static var or depend on static variables. As the cvs -> rsync box doesn't have the multislot use flag active, the portage cache gets SLOT="0". When you try to merge the package with the multislot, portage notices the ebuild wants to use SLOT="2" even though the cache has SLOT="0". @base-system: You should redesign the multislot support.
Thanks for explanation. I had no idea what do you mean by this "invariance rules" mentioned in your comment #1. Now I finally understand. So without apropriate changes in whole portage system, this little bug isn't solvable. Maybe it is apropriate closing this bugreport as CANTFIX. Thanks again for your time. Have a nice day.
*** This bug has been marked as a duplicate of bug 174407 ***
