Re: Modules packaging policy - the ocaml experience ...
Hi, ...
CCing the ocaml folk too, since they may have some insight or additional point
i lacked.
Mmm, i was going to make this a personal mail to Jurij and Steve, but i think
the info given here is worth it, and even if i am persona-non-grata, it is
good to have it here for reference. So, if you don't care about me, please
ignore it, and forget about it, no need to flame, ok ? And please take the
ideas that are worthwhile from my experience on a similar case which i give
here, and ignore the rest.
Steve, since we worked together on the ocaml case, i would like you to comment
on this, especially for the parts concerning binNMUs and testing scripts.
On Thu, Mar 23, 2006 at 09:32:04PM -0800, Jurij Smakov wrote:
> Ok, here is the idea: say we make a policy for each module-source package,
> so that we have a common interface and can automatically rebuild it. Then
> we make a package, build-depending on *all* the module-source packages
> out there, which are currently known to be policy compliant. This package
> will generate a set of binary packages (one per flavour), each of them
> will contain *all* the binary out-of-tree modules for that flavour,
> produced during build from the module-source packages. When new kernel is
> released, we test-build this package against the new kernel headers, and
> upload it, it is built on autobuilders, and produces binary packages.
> Installing linux-image-2.x.y-a-flavour and
> out-of-tree-modules-2.x.y-a-flavour
> (and, optionally, out-of-tree-non-free) puts the whole shebang in
> /lib/modules/version, and you can use the current mechanism of
> kernel-wedge and linux-kernel-di packages to split them into udebs.
I am not sure that this super-module-package is needed, as it will not do the
build all by itself. It is my strong belief that doing simply the right
dependencies and build-dependencies on those packages and letting the testing
script do the rest for us is enough. Can you please speak with Steve about
this to get an idea of it.
We have a precedent in the ocaml case, where we have a set of packages that
need to be in sync with the ocaml runtime, and use a virtual abi-package which
all ocaml packages have to depend on, and which is used to make sure that the
sync is kept when migrating to testing. Again, Steve knows about it, and i
believe we where able to do upgrades to the ocaml abi in this way in a quite
successfull and quick way, and this is a process we have going since a few
years now, with 5-6 abi migrations or so.
We need to keep a list of module packages, or thanks to the virtual abi
package maybe, have an easy way to obtain a list of them, which i believe is
already done by the RMs for the testing scripts.
> I don't think that the idea of automatic rebuilding of module-source
> packages in the archive (via binNMU or otherwise) is acceptable. I think
> it should be done by hand, so that there is at least some QA here. If the
> module-source package fails to build, it can always be temporarily removed
> from the out-of-tree-modules source package. That will also motivate people
> to update the module-source to the new kernel quicker :-).
I don't agree with this, again in the context of the ocaml package, we tried,
under Steve's tutelage, to do binNMUs of the packages during rebuild, and i
believe this doesn't cause major problems. The most probable cause of errors
are build errors, and these can be caught rather easily and handled then.
It may be more problematic with new kernel versions, but at least with abi
changes of the same version, there should be no problem in doing automated
rebuilds.
Now, contrary to the ocaml case, the modules will have the kernel version
and flavour list embedded in the package name, and thus will need a control
file change. I don't know if this is a problem, but maybe not.
The control file can be auto-generated at build time, it is only the
build-dependencies and other source-related changes which have to stay
constant, so if we do this smartly, we can allow for binNMU rebuilds of the
source package without major problem. As we have started doing for the last
ocaml abi migration.
I may have overlooked something, so please double check, but years of
experience of this kind of thing in the ocaml case may be of some interest to
you.
Friendly,
Sven Luther
Reply to: