Re: Intent to package pine-src
On Thu, 30 Apr 1998, Santiago Vila wrote:
> > We do it this way for both DFSG Free as well as for contrib and non-free
> > software, so why make an exeption in this case?
>
> Because we want to make easier the retrieving of *certain* source files.
> As easy as it is currently to retrieve binary .deb files.
How does it make it easier to force the downloader to eat the orig.tar.gz
file every time a small change is made to the package.
The source file format was designed to provide the capability of obtaining
source from other medium, download a diff and dsc file, and build the new
source tree.
How does it make it easier to be forced to eat that source tree every
time, and then not get control over where it goes or how it is unpacked.
Where do these .deb files unpack the source when they are installed? How
does the user get what he/she expects?
I can see why this "seems" to be such a simple solution...all the tools
are here and well known...the problem is that non is a "hammer". Trying to
use the binary package for source is simply...gross.
When I distribute non-free programs on CD, it is very easy to include the
source on the same directory tree, so I don't really see the gain of
bundling it all up in a .deb file, and there are good reasons for not
doins so, although you seem unreceptive to them.
>
> > Retrieval of source from archives is usually done "by hand" but any such
> > bulk retrieval should be easy to manage with a script. I take the lack of
> > a script to indicate the current relative lack of need. Anyone is welcome
> > to prove me wrong by writing such a script ;-)
>
> My point is that the functionality is already built-in in dpkg itself and
> we would not have to reinvent the wheel just for this particular case.
>
The functionality for both binary and source package management is already
built into dpkg. No wheel inventing is necessary.
I believe that you are confusing dselect's ftp method with dpkg features.
I'd much rather see Apt capable of fetching source components for a
package as easily as it does the binary ones, than to see package source
begin to migrate into the binary packaging system.
> > Although few agree with me, I still feel that packaging kernel source in
> > .deb format was/is a mistake. The kernel-package-builder package doesn't
> > benefit from this packaging style, as far as I can tell and it makes the
> > kernel more perculiar than it need be.
> >
> > Another benefit of this source format that the .deb does not provide is
> > the one time only download of orig.tar.gz. Until the upstream version
> > changes, one can keep up with the Debian package by only needing to
> > download the .diff and .dsc files (typically many orders smaller) to
> > create a source tree that will build the current version of the Debian
> > package.
>
> Ok, then I will make two packages. One for the .orig.tar.gz file and
> another one for the .diff.gz and the .dsc files. This way only the second
> one will have to be downloaded for each new release.
>
What is the point! They are already properly packaged in the source
format.
> > Keep source in Source Format and use the .deb files for what they were
> > intended, the distribution of "binary" components.
>
> I *will* keep the source in source format.
>
> I will just create another .deb binary containing the source.
>
> The .deb files were intended to be the binary package format of a free
> Unix-clone distribution, Debian. If binaries are not allowed, the .deb
> binary format is certainly not suitable for its distribution and we
> can perfectly live with an exception.
>
This is a rather circular set of logic. If binary distribution is not
allowed, how does that make the binary packaging system the right place
for the source?
If this package does not allow the distribution of binaries, then we
should distribute the package in Source Format. That is the clearest way
to satisfy the license.
Making a "pseudo" binary package is not appropriate, however, creating a
package that will "automatically" retrieve and build a Debian Source
Package would not only be acceptable, but very useful in other situations
not directly related to non-free distribution limitations.
One of our "unwritten" policies is to apply the principle of least
surprise wherever applicable. Most reasonable folks expect to find the
source in the source section, packaged like other source, in a consistent
and reliable fashion.
Luck,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: