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

Re: Bug#147077: What is with the kernel maintainer? (How not to close Bug#147077)



On Mon, May 27, 2002 at 09:31:07PM -0400, Brian Mays wrote:
> 
> Herbert Xu wrote:
> 
> > That's true only if they use yenta and did not include isa-pnp through
> > other means.
> 
> Only for yenta?  Not really.  Please look again at Bug#144613, which you
> reassigned to pcmcia-cs.  The following problem was cited in this
> report:

Sorry, I meant only i82365.  yenta does not have this problem since
it is PCI.  Most new machines come with PCMCIA/PCI bridges rather than
ISA ones.
 
> > For starters removing the symlink doesn't really solve the problem
> > that got you here.  Sure it will stop the errors in dpkg.  But it
> > doesn't solve the fundamental problem of including two sets of modules
> > with identical names under the same directory.
> 
> By this, I assume you mean under the same directory tree, e.g.,
> /lib/modules/2.4.18/.
> 
> Why exactly is this a problem?  As far as I know, this doesn't actually
> break anything.  (If it does, please provide a specific example of

The problems are:

1. The modprobe search order is not documented and may change.
2. Modprobe becomes seriously confused when two modules provide the
same symbols needed by a third module.

You can certainly solve the first problem through using insmod, however,
that brings you back to the dependency problem if that module depends on
other modules, e.g., orinoco is one such case.
 
> This is now obvious with the latest set of Debian pcmcia packages, which
> conflict with each other.  The major source of confusion that remains is
> the kernel configuration help entry for CONFIG_PCMCIA:
> 
> :: CONFIG_PCMCIA
> ::   Say Y here if you want to attach PCMCIA- or PC-cards to your Linux
> ::   computer. ...

Unfortunately there is nothing we can do about it.  A large proportion of
our users get the kernel source from kernel.org so any unilateral action
by us will not solve the problem.

> > Alternatively kernel-package could be modified to always put PCMCIA
> > modules in a separate package.
> 
> This would go a long way to clarifying things, since it would become
> obvious that a set of PCMCIA drivers has been built from the kernel
> sources.  (This is not at all obvious now, with the modules buried deep
> in the kernel-image package.)  I assumed that any scheme to do conflicts
> the right way would probably require modifications to make-kpkg to place
> the PCMCIA modules in a separate package.  I am happy to leave the
> details to you an Manoj, however.

Well my position is that this is not an issue that directly concerns me.
I am happy to provide any technical assistance to make this happen but
AFAIC there is not an issue to be addressed in any of my packages.

I won't reassign this to kernel-package since I still believe that it
is a documentation issue in pcmcia-cs.  But if you would like to take
the kernel-package approach, feel free to raise it with Manoj.

> reassign this bug to kernel-package.  As I have indicated above, I would
> still like to see the symlinks in the pcmcia subdirectory removed,
> however.

My opinion regarding the symlink is still the same: It only addresses the
symptom of the conflict rather than the cause, and it may break certain
legacy setups.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: