Metapackages for linux-restricted-modules
Matt Zimmerman
mdz at canonical.com
Tue Sep 14 13:42:31 CDT 2004
It would simplify things significantly, for the installer and for users, if
we had metapackages for linux-restricted-modules, similar to those built by
linux-image.
However, this raises the question of how to keep them in sync with the ones
built by linux-source, so that the "default version" of everything matches
up. e.g., if I install linux-image-2.6 and linux-restricted-modules-2.6,
they should be the same version and everything should work.
One way to approach it would be to have linux-source build all of the
metapackages. However, I think it might be better to have a separate source
package which builds only metapackages, as is done with gcc-defaults and
python-defaults.
So, we would have a source package 'linux', which would build binary
packages depending on concrete linux-image and linux-restricted-modules
packages. For example:
Package: linux-386
Depends: linux-image-386, linux-restricted-modules-386
Package: linux-image-386
Depends: linux-image-2.6-386
Package: linux-restricted-modules-386
Depends: linux-restricted-modules-2.6-386
Package: linux-image-2.6-386
Depends: linux-image-2.6.8.1-2-386
Package: linux-restricted-modules-2.6-386
Depends: linux-restricted-modules-2.6.8.1-2-386
etc. for each flavour. In an ideal multiarch sort of world, we could get
down to a single 'linux' metapackage which would install the appropriate
flavour and version for the system, but we're not there quite yet. :-) At
least we would be able to provide sane kernel upgrades for the common case.
Issues? Thoughts? Mark had raised a concern about aptitude's interaction
with a similar scheme, which would cause it to (by default) remove the old
kernel on upgrade, which is no good, but we already have that problem with
the existing metapackages. Maybe we can address it by having the packages
Recommend the previous version, assuming aptitude handles that in the
expected fashion. If not, I think we would still be in better shape than we
are now.
--
- mdz
More information about the sounder
mailing list