> > 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? Andy Mortimer wrote: > 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. Well, either we are going to wrap the pristine upstream sources in a "Debian format source package" -- or we are going to just store the pristine upstream sources (in tar.gz, .zip, etc, etc) in the source archive individually. If we go with pristine sources, we can't modify the package they originally came in (or the md5 checksum is different). I think that it would be pragmatic though to not allow any upstream source packages that come in a file format that can't be unwrapped by an available Debian package. Also, it might be wise to limit the variety of upstream source package formats for packages in the base system. Actually, if we used the same basic file format for source packages as we do for binary packages, we could generate Packages files for the source tree in the ftp archive. This would surely make things easier from dos. BTW: Do you know anybody who really needs to put all the tools needed to build source packages onto floppies? :-) > 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)? We should require that a Debian package is available to extract .lha files before we allow upstream .lha files into our source archive. > > > * [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. Currently, it is possible to extract the files out of any .deb file without having dpkg by using 'ar' and 'tar'. This is comparable to the effort required to extracting our current source packages by hand, for which you need 'tar' and 'patch'. There is a section in the packaging manual that explains how to do it. I wonder if it is possible to extract the files out of a .rpm file without using rpm? > > 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. I have no problem with that. I just thought it should be mentioned. > Hoping I've written at least something useful, Yes, you sure have, thanks for joining in to the debate! Cheers, - Jim
Attachment:
pgp2ZPDw6cfsl.pgp
Description: PGP signature