Re: possible compromise for ITP: linux?
Joey Hess <joeyh@debian.org> writes:
> Excuse the tautology, but I find it can be useful sometimes to look at
> requirements separate from the implementation, and try to come up with
> an alternate implementation that meets the same requirements. That other
> thread is too long for me to know for sure what all the requirements of
> the proposed linux package are, but I remember two of the main ones:
>
> 1. apt-get install linux should install the linux kernel
> 2. apt-get source linux should retrieve the source to the linux kernel
>
> Since the real source to the linux kernel is currently in the
> kernel-source-<version> package, one way to approach requirement #2
> would be to make kernel-source-2.4.22 produce a binary package named
> "linux" on the i386 architecture. On other architectures the same binary
> package would be produced by whatever package contains the real kernel
> source for that architecture. Since apt-get source resolves binary
> packages to source package, it will just work, #2 satisfied.
>
> On to meeting requirement #1. Now that we have a "linux" binary package.
> it need only depend on the appropriate kernel-image-nnn-yyy package. So
> on i386, the linux package produced by kernel-source-2.4.22 depends on
> kernel-image-2.4.22-1-386. Installation of that package installs the
> linux kernel, and upgrades are handled reasonably as well; old known
> working versions of the kernel remain on the system (if you don't want
> them to, aptitude can help). New versions of the kernel are pulled in
> as the dependencies of the linux package change to
> kernel-image-2.4.23-1-386, kernel-image-2.6.0-1-386, etc.
>
> Problems of this approach, off the top of my head:
>
> a. Having a binary package of the same name that is produced by
> different source packages on different architectures may or may not
> drive the archive maintainence scripts nuts. On the other hand,
> it uses no more space in the archive than our kernel sources use
> today.
> b. If kernel-source-2.4.22 produces a "linux" package, then when 2.4.23
> comes out, kernel-source-2.4.22 has to either be removed from the
> archive, or revved to stop providing the linux package before
> kernel-source-2.4.23 can begin to do so.
> c. After you apt-get source linux, you are left with a nice kernel tree,
> but not the .config used to build the kernel (that is in the source
> package for kernel-image-nnn-yyyy). Also, the debian/ directory is
> not set up to build a binary kernel, instead it wants to build these
> strange kernel-source "binary" packages. I'm not sure that being
> able to build the kernel is a part of requirement #2; if it is I can
> probably come up with a way around this, but it will require larger
> changes to how our kernel source is packaged.
apt-get build-dep kernel-image-nnn-yyyy
apt-get source kernel-image-nnn-yyyy
There are also kernel-tree-* package providing the right vanilla
source and patches.
MfG
Goswin
Reply to: