Re: Debian for Linux/{non-i386} / source packaging
> Before we get bogged down into the details of exactly what script
> should do what, &c, we need to consider what our requirements are, and
> make some overall design decisions. I think we have several
> conflicting requirements.
>
> 1. It is important to have a single file that can be downloaded and
> then unpacked using a single command to produce the Debianised
> source. This will make it much easier to build packages from source.
I don't consider the 'single file' necessary. I'd go for:
1(alt) have a consistent way of doing downloading and unpacking, in as
few files as possible.
> 2. It would also be good to have the same thing as above, but to
> produce the upstream source.
> 2a. That upstream source should be unmodified.
A 'unmodified upstream source + unpack/patch thingy' would not conflict
with 1(alt).
> 3. All of the ways of unpacking our source packages should unpack into
> a subdirectory, and there should be a consistent naming scheme for
> those subdirectories.
> 7. Unpacking a source package should not require one to execute parts
> of it (ie, source packages should contain only data, not code used
> during the extraction). This is important for security reasons.
If you don't trust the packaging parts, why should you trust the
claim of unmodified source?
Taking the paranoid stance here, leads to nothing IMHO.
For me, it would be enough to know that a certain package indeed came
from a known maintainer (e.g. the PGP way), and have a known developer
do an eyeball check of a first time maintainer's code.
I have more trust in "common sense" than in a complex paranoid
scheme.
> Requirements 2a and 3 are clearly in conflict.
Only when you adhere to 1, and not when you have 1(alt); then you'd have
a conflict with 7.
> As far as I can see we have one important choice to make before we
> consider any details: do we go for some kind of `proprietary' format,
> intended to be manipulable with our tools, which will enable us to
> satisfy 1, 2, 4 and 6 easily, or do we go for some straightforward
> combination of tarfiles and things, which can be manipulated by
> scripts or by hand on any sane Unix system, satisfying any two of 1, 2
> and 6, and eaily satisfying 5 and 7 ?
No proprietary format please. This would severely restrict the number
of people that benefit from it (given the current distribution of
distributions).
Ian, please take a look at Red Hat's packaging scheme.
Ray
--
ART A friend of mine in Tulsa, Okla., when I was about eleven years old.
I'd be interested to hear from him. There are so many pseudos around taking
his name in vain.
- The Hipcrime Vocab by Chad C. Mulligan
Reply to: