Bug#3057: pcmcia-cs kernel-source dependency
> Subject: Bug#3057: pcmcia-cs kernel-source dependency
> From: Oliver Oberdorf <firstname.lastname@example.org>
> My current understanding is that when I compile the PCMCIA
> package off of a particular kernel source, it is then
> dependent on that particular version. This means that my
> "-0" release of pcmcia depends on 1.3.97 and only on 97. It
> shouldn't install under 100 because it won't work on 100.
That is my understanding. Hopefully, the module format will
be fixed so that it is not as dependent on the kernel version,
but for now, we are stuck.
> I don't know alot about this - My understanding of this
> specific-version dependency comes directly from the docs
> the sources came with. These docs are installed in
> /usr/doc/pcmcia-cs by my package.
> If I am wrong - if the modules the pcmcia package produces may
> simply be "moved" into a .100 directory for kernel 1.3.100
> support, I will gladly change my package accordingly (both
> for dependencies and to auto-move to the .100 (or whatever)
> directory. I get the impression, however, that this is not
> the case.
> If I am right, the package I uploaded is only good for the
> .97 kernel. I didn't see the .97 kernel around, so shall
> I assume my -0 package is now useless? I considered uploading
> a new -1 pcmcia package based specifically on 1.3.100, but
> what would be the point in it? Version 0 still hasn't left
> Incoming so I imagine version 1 would be obsolete by the time
> it made it to misc (or whichever).
> This is why I have repeatedly asked developers what my policy
> should be. Should I include support for multiple kernels?
I like that idea. Unless the correct modules are packaged with
each kernel (see below) it would be good to have the pcmcia-cs
package provide support for multiple kernels.
> Should I put the kernel dependency in the package name
Only if each pcmcia-cs debian package supports just one kernel.
> This is also why I've asked that when a kernel is chosen
> for the installation, let me know so I can make the package
> depend on IT. That is the only way I think pcmcia-cs will
> be a useful Debian package.
> To be blunt, the only reason I'm packaging pcmcia-cs is so
> I can have it on a Debian 1.1 CD. I've put hours of work into
> packaging and testing the files I did upload. Guidelines
> have been sparse, so maybe I'm doing something wrong. I've
> asked about that before as well. I can make pcmcia-cs depend
> on uname, but currently I see no point. The .97 version is
> obsolete before leaving Incoming and I'm not spending any time
> on a successor with equally grim prospects.
> If someone wants to tell me I'm wrong about the dependency,
> great. If someone wants to tell me the version of the 1.1
> kernel so I can push pcmcia through in time for a cut, great.
> Otherwise, what would be the point in doing further work on
I contemplated taking on a pcmcia package and decided against it
because of the very problems that you are running into. I hope
that you can make it work, but if you can not, I suggest that it
be split into two parts. The modules would be packaged with the
kernels and the card services programs would be a separate
Hmm, perhaps that is an idea. Maybe if you provided the pcmcia
modules to the kernel maintainer, they could be packaged with
the kernel. Then a card services package (which would probably
not be as sensitive to kernel versions) would contain the
utilities. While we are at it, supposedly, someone is arranging
to make xforms available. When that happens, please add the
X-based card information program to the package.
> P.S. I know PCMCIA isn't on other people's agendas like it is
> on mine. I'm just saying that I'm not putting any more hours
> into it if they're going to be wasted. Currently, that is the
> case. If CDs of Debian 1.1 get cut without PCMCIA support, I'll
> likely drop the package. I don't mean to be gruff, I've mentioned
> these issues before and got practically no feedback.
(I use Debian on two laptops with pcmcia card slots, so this is
an important issue to me.)
David H. Silber email@example.com Project: Refinance the house!
<http://www.access.digex.net/~dhs/> Project: lockstep
Programmer for hire.