3rd party modules in the archive
#include <hallo.h>
* Andres Salomon [Wed, Mar 15 2006, 02:45:42PM]:
> On Wed, Mar 15, 2006 at 07:20:20PM +0100, martin f krafft wrote:
> > also sprach Gustavo Franco <gustavorfranco@gmail.com> [2006.03.15.1512 +0100]:
> For starters, I/we need to figure out a sane way to deal w/ 3rd party kernel
> modules. I'm not sure the status of this, since Sven was adamant about this
> happening his way; I'm not even willing to even touch the issue while he's
> active in the kernel team. I don't need the extra stress. If Sven remains
> active, I intend to just ignore the issue and let someone else deal w/ it;
> perhaps someone who thinks that expulsion is too harsh.
WTF has this to do with Sven now?
IIRC I tried to do something about 3rd party modules (besides of
packaging some of them and module-assistant) but had to put it on the
TODO list for-the-times-when-you-can-waste-spare-time, unfortunately not
there yet.
I see at least one big problem with such packages - some instance
between (IIRC the thing we were designing on wiki, with or without m-a
integration) has to manage the n:m mapping (n kernel flavors on all
architectures to m modules). However, I have been told that it is no
longer allowed to upload binary packages that do not appear in control
files of the source package that are claimed to be the source of the
uploaded binary package. I am sure this has been done differently in
pre-Sarge times, eg. pcmcia-modules-KVERS packages have been always
uploaded with new .changes files but without being mentinoned in
pcmcia-cs source package.
This results in a problem for any kind of additional package generator
working outside of the usual "source -> build -> upload" cycle. As a
result, people are forced to put ALL known
architectures/kernel-flavour permutations into sourcepkg/debian/control
in order to be able to upload packages build on other architectures
later. Or generate meta packages for each arch that list ALL kernel
permutations available there, also building the actual kernel packages
together with that per-arch meta package.
Or they just limit the number of available architectures to their arch
(or to i386) and list them in sourcepkg/debian/control and build the
module packages together with the source on their arch.
So or so, the mentioned limitation sucks. I wish FTP management to
accept packages of this kind again. However I realize that it would add
a lot of additional work adding them to the archive because packages
with new names may appear and disappear all the time. Therefore we need
a way to tell FTP management: packages of that kind are okay and they
shall be removed when the following package disappears: ... Maybe a new
field? Eg.
GenPkgBaseName: unionfs-module-
Having the meaning: packages matching /^unionfs-module-(.*)/ and declaring the
mentioned source package as source are installed automaticaly, and are
removed automaticaly from the archive when the package linux-image-$1
is removed.
Any better ideas?
Eduard.
Reply to: