Re: New Source Formats and Source Package Verification
On May 12, Jim Pick wrote
>
> Excellent write-up, Klee. Thanks for doing it.
I second this; a lot of thought has obviously gone into this, and it
shows!
> Since I've been attacking this topic lately, I'll try to post some (hopefully)
> constructive criticisms. But, overall, I agree with what you said.
>
> > * [1.1] It must be possible to reconstruct exactly the construction
> > of a Debian-format source package directly from upstream sources,
> > possibly with the addition of Debian-specific patches or source
> > files. Where bit-for-bit archive equivalence of upstream sources is
> > not practical (because of troublesome upstream source formats),
> > file-for-file equivalence must be provided.
>
> What's an example of a situation where bit-for-bit upstream archive
> equivalence cannot be maintained? I can't think of any situations
> where this might happen. Are there archive formats that need to be
> used that don't have utilities to unpack them available in Debian?
> > * [1.4] The end-user of a Debian system must be able to unpack and
> > examine a Debian source package without executing any code other
> > than the Debian source unpacking tool.
>
> Please clarify - unpacking a Debian source package is different
> than unpacking an upstream source package (which may require tar,
> unzip, zoo, lha, jar, etc.). Right?
Personally, I'd be inclined to disagree here, especially given [1.5]
below. If I've gone to all the trouble of downloading, putting onto
floppies, taking home and unpacking a Debian source package which I need,
I would be slightly irritated to discover that it needed some obscure
decompression tool, which not only was going to delay my actually having
the source for another day, but which would take up yet more space on my
already overcrowded hard disc.
Admittedly, I personally am unlikely to be in this situation, but I
thought it needed pointing out. It's all very well to keep the upstream
sources unmodified, but I think we should be sensible about it, and not
take it to extremes. At the very least, _ensure_the_dependencies_are_
_readable_under_dos_!
Might it be possible to, say, have a list of `supported formats' --
.tar.gz, .zip, others? -- and at least give the option of downloading
upstream sources which were originally in other formats as a tarball?
This is far from ideal, for any number of reasons (maintainer upload
time, archive space), but on the other hand it's IMHO important not to
force people to install piles of random decompression programs just to
get at the source archives.
> > * [1.5] Users of arbitrary UNIX distributions should be able to
> > unpack and examine a Debian source package with a minimum of
> > complexity, and must be able to unpack it without any non-standard
> > tools, and without executing any arbitrary code.
>
> Same thing as my previous comment. I just want to make sure that
> you're not suggesting that we impose conditions on the format of the
> packages that come from upstream sources.
So our hypothetical user can unpack all the required .lha files and
Debian patches, but cannot actually see the source without finding and
compiling an lha program (which may well come as a .lha archive from the
upstream maintainer anyway)?
> > * [2.7] It should be possible to build a Debian-format source package
> > in a controlled build environment, without the need for root privileges.
I concur; IMHO, this should have happened a while ago. But then, ISTR
some security objections etc, which I never really understood: anyone?
[snip]
> > * [3.3] It should be independent of dpkg and the binary packaging
> > system --- those are complex enough already.
>
> Why? I think it would be a good idea to re-use the new cryptographically
> signed binary format you are going to have to create to also package
> the source packages. Red Hat does this.
Go reread [1.5] above, and then consider whether you /really/ want to
require dpkg to be present in order to unpack the dpkg source ... that
is at least part of the reason for `why'. And it's been snipped, but one
of the points was that it should be possible to generate .tar.gz, .rpm,
and so on from the same source archive; if we're going to do this, then
forcing the whole world to install dpkg first is going to seriously
reduce the chances of this being viable.
> It just makes sense. You will also want to reuse the "dependencies
> on binary packages" from out of dpkg.
I'm sure a lot of the code will come from dpkg; when it's done, it would
seem to make sense to use the projected `libdpkg' for this sort of
purpose. But I see absolutely no reason to constrain ourselves to the
format we already have just because we already have it.
> An easy way to do this would be to modify dpkg to consider source packages
> as just a special type of binary package. Again, Red Hat already
> does this. It would only add another 2-3% more complexity to dpkg,
> if done right. That's a lot less complexity than writing a whole new
> source package handling system.
> > * [3.4] It should require only moderate changes to dpkg-dev and to
> > the FTP installation tools. I don't like to make work for myself,
> > and I especially don't like to make work for Guy Maor. Any proposed
> > changes should be able to be implemented by a single person by
> > July first.
>
> If source packages were just a specialized format of the binary package
> format - they could be handled the same way, and using the same tools.
> Ask Guy which part of the tree is more consistant and easier to handle
> - the source code part or the binary packages part?
Surely a lot of the inconsistency here comes from the fact that one
package <--> one file in the binary tree, but not in the source tree.
None of the mechanisms recently discussed are going to change that, so
far as I can tell.
> > * [5.1] Binary package verification (the issues here are substantially
> > similar to those of source package verification).
>
> We should use the same package format for binary and source packages,
> so they could both be signed the same way.
We could, yes. But why should we? I think this is too early to be
discussing implementations, and we should concentrate on working out what
we want from this, rather than how we're going to get it.
> Red Hat does.
So?
[snip summary]
Obviously we're coming at this from very different angles, but the
important points for me in Klee's proposal are portability and
ease-of-use, rather than reuse of code. It is quite possible to have a
fairly sophisticated system, without just hacking something else, and
without having to live in monastic seclusion for a month in order to get
all the code written!
Hoping I've written at least something useful,
&E
--
Andy Mortimer, andy.mortimer@poboxes.com
http://www.netforward.com/poboxes/?andy.mortimer
Finger asm21@asm21.emma.cam.ac.uk for PGP public key
--
Give me life, give me pain,
Give me myself again.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: