Subject: Re: kernel-source and kernel-headers packages

From: Dale Scheetz <[email-masked]>
Date: Mon, 1 Jul 1996 09:35:06 -0400 (EDT)

On 30 Jun 1996, Manoj Srivastava wrote:

> >>"Ian" == Ian Jackson <[email-masked]> writes:
> 
> Ian> The /usr/src/linux symlink is no longer necessary for anything
> Ian> very much, and in any case it seems to me that having the
> Ian> most-recently-unpacked thing alway set this link to itself is
> Ian> bad.
> 
> 	Umm, I could not think of another scheme that was better ;-),
>  and I think it works for most people most of the time.

What was wrong with: kernel-source-2.0.tar.gz? This is how we distribute
all other source.

> 
> Ian> But really the main problem is that a .deb package is a
> Ian> stunningly bad way of distributing source code - it's exactly the
> Ian> kind of thing that dpkg (and indeed almost any package management
> Ian> scheme for binary packages) will have huge trouble with, because
> Ian> people will always be editing it, compiling it, rm -rf'ing it,
> Ian> &c.
> 
> 	Well, yes, but .deb packages are how we distribute packaged
>  products to the debian users (most methods of delivering such
>  products to the end-user are focussed on .deb format (dftp, dpkg-ftp,
>  and cdrom distributors)), so if Debian is to provide the sources, it
>  should be in this form (I dislike to think that there is a special
>  case made for the kernel sources).
> 
.deb packages are how we distribute BINARY packages. Dftp and dpkg-ftp are
scripts, so the 'binary' and the 'source' are the same. I didn't know that
we distributed cdrom distributors in .deb format. I'll have to try that on
myself and see how it feels :-)

> 	  I think that there is a demand for kernel sources, and that
>   we should satisfy this need, if only for completeness. Also, though
>   there are not now, but there may be, in the future, packages that
>   really depend on the kernel sources; and the .deb file defines a
>   standard place to find kernel sources on a Debian system
> 
We should satisfy this need for source the same way that Linus does, with
a tar.gz file. Any packages that explicity depend on a particular kernel
are broken at birth and has absolutely nothing to do with HOW source files
are packaged.

> 	Methinks, Ian, you underestimate your creation, dpkg handles
>  the sources well enough in most of the cases.  So far, I have no
>  complaint about dpkg's handling of the sources, indeed, people savvy
>  enough to edit kernel sources are usually savvy enough to understand
>  why dpkg is complaining about extra files while deleting the source
>  package (indeed, one may edit the sources almost at will, with no ill
>  effect, only adding files seems to discomfit dpkg).
> 
Methinks it is your understanding of dpkg that is lacking. I guess my
complaints don't count, because you fixed the problem created by dpkg in
your original implimentation. I contend that there are still problems with
this approach that will come back to haunt us later.

Personaly, I will continue to get kernel sources from the "true source"
and build them the way I always have. These kernel packages will not bite
me, because I will not use them.

Thanks for all your other work,

Dwarf

------------                                          --------------

aka   Dale Scheetz                   Phone:   1 (904) 877-0257
      Flexible Software              Fax:     NONE 
      Black Creek Critters           e-mail:  [email-masked]

------------ If you don't see what you want, just ask --------------

---

From: "James D. Freels" <[email-masked]>
Date: Mon, 1 Jul 96 09:04 EDT

> and I think it works for most people most of the time.

... stuff deleted...

>	manoj

I agree here also.  For most folks who even recompile the kernel, the
only thing that will change is the /usr/src/linux/.config file.  I
keep a backup set of these for different machines in my /root area.
Well, I also changed the /drivers/sound area on my home machine to
incorporate the latests USS/Lit source.
-- 
/------------------------------------------------------------------\
| James D. Freels, P.E._i, Ph.D.  | Phone:  (423)576-8645  |   | L |
| Oak Ridge National Laboratory   | FAX:    (423)574-9172  | H | I |
| Research Reactors Division      | Internet: [email-masked] | F | N |
| P. O. Box 2008                  | Reactor Technology     | I | U |
| Oak Ridge, Tennessee 37831-6392 | world's best neutrons! | R | X |
|------------------------------------------------------------------|
| out the 10Base-T, through the router, down the T1, over the      |
| leased line, off the bridge, past the firewall...nothing but Net |
\------------------------------------------------------------------/

---

From: Manoj Srivastava <[email-masked]>
Date: 01 Jul 1996 18:00:50 -0400

>>"Dale" == Dale Scheetz <[email-masked]> writes:

Dale> What was wrong with: kernel-source-2.0.tar.gz? This is how we
Dale> distribute all other source.

Dale> .deb packages are how we distribute BINARY packages. Dftp and
Dale> dpkg-ftp are scripts, so the 'binary' and the 'source' are the
Dale> same. I didn't know that we distributed cdrom distributors in
Dale> .deb format. I'll have to try that on myself and see how it
Dale> feels :-)

	I think this is confused.  Firstly, it is difficult to define
 what you mean by BINARY packages, if it means that the packages
 contain binaries, then that is patently incorrect, since a number of
 packages (all the emacs .el/.elc packages, all the documentation
 packages, and maybe even the termcap compat packages do not contain
 executables).  What *does* binary mean in this context? Surely yu
 don't mean that the package contain atleast one file that has
 non-printable characters ;-), even then, the doc-debian package would
 violate that.

	So.  I think that the following is closer to the truth:

 .deb files contain, in a packaged form, a directory tree structure
      that is targeted to be installed on an *users* machine, along
      with control information for the packaging system.  Debian
      attempts to ensure that the directory tree contained follows a
      standard ("FSSTND").
 tar.gz files in the source area of debian archives contain the
      sources for debian packages, and are targeted at *developers*,
      or people who compile their own packages.These do not unpack to
      a well known place in the directory structure, and are not
      managed by the package management system.

	I wish to provide the kernel sources are a package to
 *users*.  This is not a source for a debian package, but a source for
 the linux kernel, like the .el files are sources for the Emacs lisp
 system. This is different from the kernel-source-X.X.XX.tar.gz, since
 the latter would contain debian* files, I want to deliver the
 pristine sources as debian-source-2.0.0-1.1.tar.gz, which unpacks
 into a pristine /usr/src/kernel-source-2.0.0
 tree. kernel-source-X.X.XX.tar.gz, on the other hand, would unpack
 into ./kernel-source-2.0.0 and contain debian files (at least, untill
 we move to the new system)

	In any case, I would like to bring the kernel sources to the
 masses, by providing thenm with a .deb package that delivers the
 surce, and can be retrieved, managed, and disposed of like any other
 package. 

>> I think that there is a demand for kernel sources, and that we
>> should satisfy this need, if only for completeness. Also, though
Dale> We should satisfy this need for source the same way that Linus
Dale> does, with a tar.gz file. Any packages that explicity depend on
Dale> a particular kernel are broken at birth and has absolutely
Dale> nothing to do with HOW source files are packaged.

	I disagree.  We have created a vehicle for delivering
 goodies (libs, executables, and other files) to the user, and we
 should use it.  It works. We have invested in this process. The
 original authors of most of our packages have different ways of
 delivering their packages to their users, this does not, and should
 not, be used as a reason to abandon our packaging scheme (no matter
 how we admire the aforementioned authors ;-).

>> Methinks, Ian, you underestimate your creation, dpkg handles the
>> sources well enough in most of the cases.  So far, I have no
>> complaint about dpkg's handling of the sources, indeed, people
>> savvy enough to edit kernel sources are usually savvy enough to
>> understand why dpkg is complaining about extra files while deleting
>> the source package (indeed, one may edit the sources almost at
>> will, with no ill effect, only adding files seems to discomfit
>> dpkg).
>> 
Dale> Methinks it is your understanding of dpkg that is lacking. I
Dale> guess my complaints don't count, because you fixed the problem
Dale> created by dpkg in your original implimentation. I contend that
Dale> there are still problems with this approach that will come back
Dale> to haunt us later.

	I think thee raises specteres from the dark where none exist,
 I think that the dpkg mechanism serves well enough, and we shall deal
 with the infelicitous bites when we see them.

Dale> Personaly, I will continue to get kernel sources from the "true
Dale> source" and build them the way I always have. These kernel
Dale> packages will not bite me, because I will not use them.

	I strongly defend your right to disdain the kernel-sources
 packages. You may like the newer version of kernel-package better,
 though, they unpack in /usr/lib/kernel-packages, and provide a method
 to

 % cd <pristine kernel source directory>
 % make menuconfig
 % /usr/sbin/make-kpkg kernel_image

	and you are done.

Dale> Thanks for all your other work,

	manoj

-- 
 "The vast majority of successful major crimes against property are
 perpetrated by individuals abusing positions of trust." Lawrence
 Dalzell
Manoj Srivastava               Systems Research Programmer, Project Pilgrim,
Phone: (413) 545-3918                A143B Lederle Graduate Research Center,
Fax:   (413) 545-1249         University of Massachusetts, Amherst, MA 01003
<[email-masked]> <URL:http://www.pilgrim.umass.edu/%7Esrivasta/>

---

From: Dale Scheetz <[email-masked]>
Date: Mon, 1 Jul 1996 20:34:30 -0400 (EDT)

>  non-printable characters ;-), even then, the doc-debian package would

What it means is EXECUTABLE. Scripts are not strictly binaries, but they
are executable. That is why the above items are packaged. Termcap, if I'm
not mistaken contains a.out libraries. Libraries can also be considered
whithin this binary concept. But source code that is expected to be fed to
a compiler does not.

>       managed by the package management system.
Well I think you still miss the point. Tar.gz files ARE useful to
developers, but they are provided for everyone. Many users prefer to build
from source, rather than trust an unknown binary package.

>  *users*. 

Then put it in a tar.gz file and call it a source package, since that is
what it is.

 This is not a source for a debian package, but a source for
>  system.

Of course it is! As I understand it, you can build a kernel image package
from this source package. These sources go through a compiler. The .el
files are executed/interpreted to perform their desired functions. They
are executables.

 This is different from the kernel-source-X.X.XX.tar.gz, since
>  the latter would contain debian* files,

None of the kernel sources I get from Linus have any debian* files in
them?

 I want to deliver the
>  we move to the new system)
Well, if this is, in fact, the way your are doing it, you should switch
the names. Anything with the name debian in it should not be pristine
source. I would expec to find debian* files in the
debian-source-xxx.tar.gz file and to find none in a file called
kernel-source-xxxx.tar.gz. You have no work to perform to create pristine
source, just get it from Linus. 

>  surce, and can be retrieved, managed, and disposed of like any other
Except that the kernel isn't "just like any other package". It is the
environment in which packages and package management systems live.

>  how we admire the aforementioned authors ;-).

We deliver source to users in tar.gz files. An attempt to make this a
special case is unwarranted.

>  with the infelicitous bites when we see them.
Using dpkg mechanisms in a venue that it was not designed for is just
asking for trouble and confusion.

>  % /usr/sbin/make-kpkg kernel_image

And you have just created a binary package, right? That makes the other
thing a source package which has been mistakenly dressed up as a binary
package.

Dwarf

------------ If you don't see what you want, just ask --------------