That's because if USE="alsa" is used, some packages require virtual/alsa, that is alsa-driver. It requires kernel headers. Installing linux-sources doesn't help (as alsa requires them). Maybe there should be a "emerge -i virtual/alsa" somewhere... Maybe a "injected packages" section in grp specfiles? Reproducible: Always Steps to Reproduce: 1. Create a specfile for GRP which has USE="alsa" 2. Run catalyst to create that GRP. Actual Results: It tries to install alsa-driver, and fails. Expected Results: Do not require alsa-driver.
Created attachment 38242 [details] Adds a 'injset' type for packages to be injected. Well, the file is a 'patch', but I don't have cvs access, so I cannot generate a good file for 'patch' unix utility. :) That's a diff from old to new file content. Please test it. It works for me.
(I added that file (grp-chroot.sh.diff). I didn't know how bugzilla worked... So here is the explanation. :) I've changed "grp-chroot.sh" to allow new type "injset", for packages to be injected. Thanks to that, a new grp type can be added, that way: grp/inject/type: injset grp/inject/packages: alsa-driver
Oh. I thought "WORKSFORME" wasn't at closed state. The bug isn't closed. Or is it? The change isn't in CVS. Well, I won't touch this bugzilla anymore that way. Excuses.
actually, the correct way to do this is to add kernel sources dependent packages to "boot/kernel/$x/packages" where x is the name of the kernel specified in "boot/kernel".
Ok John. Bug is reopened.
Thanks, I will look into it!
actually, wouldn't this fail anyway due to the lack of header files? alsa would probably just bail anyway... I think that most packages would be like this. Would an option like this really be that beneficial?
alsa-driver cannot find kernel header files, as there isn't a kernel installed (so there aren't kernel include files in /usr/include). That way, injecting alsa-driver makes everything to work. I don't understand the use of "bail" there. Can you write that sentence in another way? :) Sorry, I'm not English native, and using a dictionary didn't help.
sorry for the jargon :) bail is slang for "stopping due to an error". The context is similar to that of jumping out of a sinking ship or jumping out of a crashing airplane (I am bailing out of the airplane). Regardless, I misread your comment. I will be adding this feature into catalyst CVS soon.
Well, the normal solution for this would be to move the offending packages to livecd-stage2 under either a boot/kernel/$kname/postconf or boot/kernel/$kname/packages, as you don't really want to inject the package, but rather to fulfill the virtual. Also, if you're using a kernel sources that fills this virtual (the reason for injection), then just add the sources into livecd-stage1 before the rest of the packages. Besides, package injection has been deprecated by package.provided, which is usable by using the portage_confdir setting in your spec files. Either way, this functionality is already present in catalyst, just not 100% how you requested it. Personally, I don't think this should be added to catalyst simply because it is using a deprecated interface to portage. John, if you disagree, feel free to REOPEN this one.
Oh yeah... and reassign to catalyst@.... :P
I've been dealing with the newest portage... I changed the code of my 'catalyst' about 'injection', to that which supplies 'provided'. I haven't merged my catalyst tree (the one I use) with the current CVS one. I will. :) I promise. By now I have a 'dirdiff' opened, for merging the files. hehehe. I should have maintained a changelog of the changes to catalyst 1.0.9 :) Maybe I should check the log of my subversion. I completely agree with Chris.
I want to use portage_confdir... but I see (in catalyst 1.1.0) that that option is related to stages. The 'inject' proposal was related to the GRP... but the option you talk about is in "livecd_stage2" and in generic_stage catalyst modules. So... do you think that this feature (about injection, "provided", or however you call it) should be in stages, instead of in GRP building? - I even don't know if this is the best location for a discussion about this. Maybe the 'releng' list is better?
Oh, I'm sorry. I forgot that the code about 'unpack' stages is in generic_stage_target.py now that's working for me. thanks. :)
