Summary: | alsa driver cannot be installed when making GRP with USE="alsa" in specfile. | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Lluís Batlle i Rossell <viric> |
Component: | Catalyst | Assignee: | John Davis (zhen) (RETIRED) <zhen> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Adds a 'injset' type for packages to be injected. |
Description
Lluís Batlle i Rossell
2004-08-25 01:00:32 UTC
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. :) |