Hi, I've had a couple of gripes with how pcmcia-cs is packaged. This ebuild here fixes a couple of the issues. Let it be said that pcmcia-cs is a complicated piece of software and I'm sure its difficult to accomodate everyone :) 1. I have problems running i82365 on my Sony Vaio N505VE. It is actually listed in the BUGS file that there are problems with that particular PCIC module with my laptop. Hence, I have the kernel yenta_socket module compiled, but then pcmcia-cs refuses to compile the wireless and client modules automatically. Again, from the README, it says you can manually compile these modules by running 'make' in the subdirs wireless/ and clients/. And this is what this ebuild does. It also gets around the CardServices version mismatch by patching the version.h with the pcmcia version from linux headers. 2. The init script for pcmcia (/etc/init.d/pcmcia) doesn't load or unload the kernel modules automatically. This patch checks: a) whether these modules are loaded/unloaded b) whether PCIC is set in /etc/conf.d/pcmcia and loads the appropriate modules rather than just "warn" the user as it does. 3. /etc/conf.d/pcmcia needs to enable the use of PCIC. We need to mandate that so people specify in there what PCIC they are using, whether they use the kernel one or the pcmcia-cs one. 4. Fixed the postinst message which tells users they can have the kernel pcmcia config enabled and have the modules compiled, the best of both worlds. I hope that at least some, if not all, the changes will be considered which will make life much much easier for laptop users. And if there are some questions or problems with my ebuild and changes, I would gladly like to discuss them. Cheers, Alastair
Created attachment 3931 [details] improved ebuild to compile pcmcia-cs modules regardless
Created attachment 3932 [details] sample /etc/conf.d/pcmcia with PCIC enabled
Created attachment 3933 [details] new /etc/init.d/pcmcia notice that it adds depend(), which i'm not too sure where it should be added before or after .. so its just the options that suit me
Okay, here are my questions (the answers to some are implied by your notes below, but I'll ask just to be sure): 1. Is it safe to use pcmcia-cs modules with yenta_socket? 2. Is it safe to use kernel pcmcia modules with i82365? 3. Are there any naming conflicts between pcmcia-cs modules and kernel pcmcia modules? These are the kinds of questions that led us to the current scheme. If you can assure me (or point me to info that assures me) that it is safe to use both schemes at the same time, then I am all for this. Actually, what would make this a lot easier to deal with would be to extract the pcmcia utilities from the modules. And maybe even make separate builds for each module, so the user could pick and choose.
Created attachment 6530 [details] pcmcia-cs-modules-3.2.3.ebuild - builds only the pcmcia modules hi, that is exactly what i came up with a couple of days ago. here is what i made to do just that on my laptop. however, i haven't thoroughly tested it. you'll notice that the ebuild will go and try to fix the pcmcia headers to match the kernel card services version. imo, it needs to be a little smarter. unfortunately, i'm going to be away for the next 2 weeks, so i'm just submitting this now and hopefully come back to improving it. cheers, alastair
Okay. I worked on this a while back and then lost all my work (thanks MS fdisk/format!). I have just committed sys-apps/pcmcia-cs-drivers and sys-apps/pcmcia-cs-tools ebuilds that effectively break the pcmcia-cs install in half. Unfortunately, the drivers do conflict with the kernel drivers, but I don't see any way around that. When these two ebuilds become standard, I will release a howto that details how to avoid conflicts. I think having split ebuilds will make it easier to explain, though. The pcmcia-cs-tools ebuild is safe to install no matter what modules you use. You will notice that my pcmcia-cs-drivers is pretty much based on your submission. Thanks!
closing this bug. pcmcia-cs-drivers by chadh addresses all the concerns of this bug.
