From: Jim Pick <[EMAIL PROTECTED]>
> Most of the opposition appears to be based on the fact that I have
> violated some aesthetic
This is on target. There is indeed an aesthetic that is an important
part of software architecture. The best software is not simply
functional, but beautiful. Much that we like about Unix and Linux
falls into this category. When one starts with a well-thought-out
design and arrives at a tool with simplicity and power, you can
sometimes achieve this kind of beauty. Ian's metaphor of using a
screwdriver to drive a nail describes his esthetic perception of your
design. I was not as eloquent in stating my own feelings, but they were
similar. I think continued work on systems programming tasks will bring
you a similar esthetic sense.
It is an excellent hack. Accept that it's a great hack, take the good
ideas from it, and go on.
> 1) How do you propose modifying dpkg-source for handling additions
> of binary files to Debian packages (without uuencoding them)?
I'll repeat the suggestion I've already made.
Detect files that are not plain text ("diff" does this for us), compare
them with "cmp", and build a tar archive with debian-changed binary files.
In this case the .dsc file would contain:
hello-1.3.tar.gz
hello_1.3-1.diff.gz
hello_1.3-1.changed-binaries.tar.gz
The changed-binaries tar file would be extracted after the original source
tar file.
> 2) How do you propose modifying dpkg-source so that you can support
> sharing upstream source between packages (ie. checker)?
Obivously you will need to know the location of the other source package,
and refer to its files. Is this any different from your proposal?
> 3) What if the upstream source comes in multiple files? How do you
> propose changing dpkg-source to use pristine-sources for that?
I propose that we make dpkg-source accomodate any number of source archive
files and diff files. We've already discussed this quite a while ago.
> 4) Can you describe an algorithm for an auto-bootstrap compilation
> mechanism in detail?
I can describe it the way I want it to run when building an entire release.
First, you extract _all_ of the source packages. The packages have binary
dependencies, and you build them in dependency order, and install the
packages as they are built.
Now, you might want to add features to handle circular dependencies and
to extract only the source that is necessary for building and clean it up
after it's built, but that should come after we get the above working.
> I'm sort of reluctant to scrap my proposal based on this assertion.
You didn't put much work into it, only part of a day. You learned some
things for what you did put in. It would be a much worse mistake to invest
a lot more work into it.
> Alternatively, take it from me as the author of dpkg: dpkg and .deb
> files are almost completely wrong for source packages. There's
> nothing that a .deb file could do for a source package that couldn't
> be done better and more simply by a .tar.gz file. All the features in
> .deb files - including the dependency mechanisms - are closely tied to
> the semantics of runtime package installation and management.
Perhaps I should use rpm for my example instead? I am just arguing for
the use of a packaging system for the delivery of source code, and a
nice separation of the upstream source and debian-specific source
directories, and the build-time temp directories.
> What you're essentially trying to do is to use a screwdriver to drive
> in a nail. You can't make up your mind which end of the screwdriver
> you want to use - the point (dpkg), or the handle (dpkg-deb) - but
> both are completely unsuited.
> I am approaching it from the premise that a .deb file is just an 'ar'
> file with two tarballs inside - one for control info and one for
> binaries.
The package file format is not the problem. It's the fact that you are
using the binary package tool to do something it was not designed for.
Thanks
Bruce
--
Can you get your operating system fixed when you need it?
Linux - the supportable operating system. http://www.debian.org/support.html
Bruce Perens K6BP [EMAIL PROTECTED] NEW PHONE NUMBER: 510-620-3502
