[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Danger Will Robinson! Danger! (PCMCIA anyone?)

> On Sat, Mar 11, 2000 at 11:44:39PM -0600, Manoj Srivastava wrote:

> >         Why is it bad having a stable kernel installed as default,
> >  and a 2.4-pre kernel, marked as extra, with warning in the long
> >  description, also in the distribution?

Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) added:

> Nothing wrong about that, if we don't go a long way to make additional
> changes in the various admin packages (isdn, pcmcia comes to mind).

Marcus is correct and has touched on something that most of those
calling for the "latest and greatest" kernel haven't considered.  It is
easy for them to emphatically demand the latest version of the kernel,
since they do not have to do the work or deal with the consequences, but
there are several additional points that need to be addressed.  The one
that concerns me personally (as the PCMCIA maintainer) is whether we
shall also provide PCMCIA support for this kernel.

I can tell you from experience that PCMCIA support lags kernel
development.  Therefore, support for a new kernel will not be available
until the next upstream release (at the earliest).  This in itself
creates problems, since this new release will be several releases beyond
the current packages in potato and new releases do often break things,
as the bug logs for pcmcia-cs demonstrate.

This problem is not simple enough that it is possible to merely build
a new pcmcia-modules-2.4-pre package.  Since all of the pcmcia-modules
package depend on a pcmcia-cs package with the same upstream version
number, upgrading the version of one of the pcmcia-modules packages
requires that ALL of the pcmcia-modules and pcmcia-cs packages must be
upgraded to maintain compatibility.

I would like to avoid what has been done in slink, where someone
(Vincent Renardias <vincent@debian.org>) did a NMU of a new
pcmcia-modules package and broke the dependencies of all of the other
PCMCIA packages.  This is particularly annoying for me, since I was
not consulted before this NMU was done (which is too bad, since I am a
helpful maintainer -- just ask anyone who has worked with me on rxvt
-- and could have warned him of this problem).  By the way, this still
needs to be fixed.  Is anyone willing to rebuild the PCMCIA packages for
slink to fix this problem?  Please.

I'll end with my main question: what is to be done about PCMCIA support
for this new proposed kernel package?


Reply to: