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

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.


Reply to: