Re: Decision about oot-modules for etch
* Daniel Baumann (daniel@debian.org) [060731 12:46]:
> Now, I would like to have a definitive statement for that to get
> everything prepared for etch (basically the ipw packages[2]). This
> means, a decision of the kernel-team and the release-team is required.
I don't see any release-team decisions required right now. :)
Basically, I tend to something like:
> * Will be oot-modules in main outside of the linux-modules-extra be
> removed by the release-team for etch?
If there are fewer (source) packages to be rebuild in case of kernel abi
changes, that's something good. If "all important" modules are there, we
might consider to deprecate/disallow other packages to require to be
rebuild in case of kernel changes. I don't really mind to make one
exception for some package if there are good reasons; but if that means
that 40 maintainers start jumping because their package should get the
exception, that boils down to no exception. :)
As to allow new packages with build oot-modules: I'm not too sure if we
should allow that, as every module makes a kernel update more
complicated. But of course, you could try to convince us that ipw is
important enough for that.
> * If no conglomeration package for contrib modules, will oot-modules
> of contrib be removed by the release-team for etch?
Same for contrib: If there is no alternative to single packages, well,
we need to use single packages. Also, how many packages in contrib
generate oot-modules? If there are only 1 or 2, why bother?
> * If contrib oot-modules outside of a conglomeration packages will not
> be removed, will it be possible to have updates to the usual
> conditions for point-releases, or, will this be refused for
> oot-modules of contrib given no contrib-conglomeration package is
> done?
I don't see a reason to refuse upgrades during point release right now.
If the oot-package with their own modules are updated, everything is
fine. Updates during point release are more problematic with a
conglomeration package, as all binary packages need to be rebuild,
forcing users a (potentially) unneeded package upgrade. (Of course,
there are the normal rules for stable updates as well.)
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Reply to: