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

Solution for module problem

Hi folks

I got another request to at least partially fix the modules mess. D-I
needs at least one of them for there kernel builds.

The current situation should be clear.
- It needs manual uploads for each source which builds binary modules.
  As the maintainer is not the kernel team, this may need some time.
- Clutters the archive with many packages.

Sven Luther proposed to integrate this packages into the kernel team but
don't propose a fix for the other problems.

So I propose another solution which will fix both the problems.
- One source package (linux-modules-extra-2.6).
- Produces currently _one_ binary package per kernel flavour.

- This solution replaces human intervention to upload a lot of packages
  with time on the buildds, which can be considered as cheaper.
- Much less binary packages needed.
- It can scale to a scheme where we want to maintain more than one
  version before release.

- It needs more communication between the maintainers of the source
  packages and the kernel team. An error in one of them will make the
  build of the whole package fail.

I got support for that solution from two maintainers of such modules,
Max Vozeler (loop-aes-modules) and Kilian Krause in favour of the
pkg-voip team (zaptel-modules).

A defined the following requirements for inclusion in this package:
- They need to provide proper Makefiles 
  (make -C /lib/modules/$(uname -r)/build M=$(pwd) have to work).
- Responsive maintainers.
- License GPL or compatible.
- In main.

I asked Max to compile a list of possible modules for this package
according to this premises. You can see the current state here[1].


[1] http://nusquama.org/~max/debian/modules/

Our missions are peaceful -- not for conquest.  When we do battle, it
is only because we have no choice.
		-- Kirk, "The Squire of Gothos", stardate 2124.5

Attachment: signature.asc
Description: Digital signature

Reply to: