Packaging philosophy question:
Sorry if there's some policy about this I'm unaware of, but
here's my question:
I have put together a PCMCIA .deb file. The PCMCIA support
is dependent on the kernel version. My main intent is that
someone installing Debian's GNU/Linux will have access to
PCMCIA services without installing the developer's series
and a kernel from floppy just to comile pcmcia-cs from
sources. So my first question is how can I ensure that
pcmcia-cs matches the installation kernel? I'm thinking
perhaps I should wait to release the package until the
installation floppy has stabilized on a specific kernel.
Better than having 3 successive versions of pcmcia-cs all
depending on different kernels.
My second question is, considering the version dependency,
should I indicate in some way which kernel version the
package relies on? That is, have something like
"pcmcia-cs-k1.3.97-2.8.12-0.deb"? Alternatively, I could
have the binary package include modules for a set of
kernels, say 1.3.64, 1.3.97, etc. This would make the
package larger, but be more flexible. Only the most recent
three kernels compiled against would remain as part of the
package. This way, 1.3.97 would work with the pcmcia-cs
today, but pcmcia-cs-..-2.deb would still support it months
down the road.
I appreciate any input on this.
Current status is that I have a working package built around
1.3.97. I've installed/removed it a gazillion times and
everything seems fine. I can do a source package, too. I
just have to add a dependency to the control files for the
kernel - something like "kernel-source(=1.3.97) |
kernel-image(=1.3.97)"?, but I'd like to know what kernel(s)
I *should* be using. The current package appears to work
fine off of the kernel-image-1.3.97 and is about 200k by
itself.
Cheers,
Oly
Reply to: