Re: Bug#147077: New directions for Debian PCMCIA support
I'm currently putting a little work in the next release of Debian's
PCMCIA packages. Please note the following changes to the way things
are done with respect to the kernel PCMCIA drivers:
1) A set of pcmcia-modules packages will continue to be built against
the kernel-image packages supplied by Debian. Since as of the 2.4.18
kernels, the kernel drivers have been split off into their own
packages -- the kernel-pcmcia-modules packages, which conflict with
the pcmcia-modules packages -- this should not be a problem.
2) Following changes upstream, the kernel drivers are now preferred over
the stand-alone drivers, if somehow both sets of drivers are
installed for the same kernel. This should simplify things for
everyone.
3) The stand-alone modules have been modified (renamed differently) to
be more compatible with (mistakes made in naming) the kernel drivers.
Thus, one configuration file now works with both sets of drivers.
4) It is now impossible to build a pcmcia-modules package against a
kernel image with PCMCIA support (either via modules or complied in)
without overriding the process. This will prevent users from
unknowingly building and trying to install both sets of PCMCIA
drivers.
Forcing the package to build the stand-alone drivers is accomplished
via an environment variable. Thus, setting FORCE_CONFIG_PCMCIA=y
should be used to build the pcmcia-modules packages to accompany the
official Debian kernel images. This will mean that whatever
autobuilders we use will have to take this into account, but such a
system needs to be customized to some degree to pull off building
PCMCIA modules in the first place.
With these new changes, much of what was being discussed in this bug
report becomes moot. The only minor point I have is in response to the
following:
>>"Manoj" == Manoj Srivastava <srivasta@debian.org> wrote:
Manoj> b) The preinst could check for the symlinks before install,
Manoj> and ask the users to remove them, or abort install, or
Manoj> whatever. This educates the users, and allows the human to
Manoj> take corrective action as needed.
>>"Brian" == Brian Mays <brian@debian.org> asked:
Brian> How can the preinst remove symlinks that belong to (i.e.,
Brian> are contained as part of) another package? That is
Brian> clearly a violation of policy, UNLESS these "compatibility
Brian> symlinks" are not contained in the kernel-image (or
Brian> kernel-pcmcia-modules) package, but are created by that
Brian> package's postinst script.
Manoj> No, I said "Ask the users to remove the symlinks". So,
Manoj> go ahead, remove the symlinks, come back, and hit enter while
Manoj> I wait and whistle at the flowers. The sysadmin can remove
Manoj> any symlink he/she wants, it is their machine.
Manoj> If not, you can just abort at that point; the human can
Manoj> decide to use the kernel pcmcia modules, recompile a kenrel
Manoj> and pcmcia modules (built in or stand alone), remove the
Manoj> symlinks and retry, or whatever. The human gets to decide, we
Manoj> just provide the tools that they can use.
This strategy still will not work, since there is no guarantee that the
pcmcia-modules package will be installed after the kernel image is
installed. It is possible to install the pcmcia-modules package first,
when there are no symlinks to find, and then install the kernel image,
which will result in dpkg complaining of file conflicts if the image is
installed from a package or, even worse, will result in the symlinks
*overwriting* the pcmcia modules if the image is installed via "make
install".
If checks in the preinst script are to be used to prevent conflicts,
then these checks must be placed in both packages. Placing them in one
will not suffice. A better alternative, if the symlinks are absolutely
necessary, would be to have the kernel-image package create these links
in its postinst. Since these would not be files managed by dpkg, there
would be no file conflicts. Indeed the stand-alone drivers could simply
overwrite the links, which would be desired. The postinst script could
check to see whether the pcmcia modules are already there before
creating the links, something that the kernel source itself does not do.
Ultimately, this probably doesn't matter, since I have aimed to
eliminate the problem before it occurs. The stand-alone modules will
not be built, unless the user goes to the trouble to force them to be
built. Caveat actor.
- Brian
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: