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

Re: possible compromise for ITP: linux?

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
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.

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: