Pristine source archive

Glenn McGrath bug1 at optushome.com.au
Sat Apr 13 08:32:57 UTC 2002


On Sat, 13 Apr 2002 08:06:19 +0000
"M. Drew Streib" <dtype at dtype.org> wrote:

> On Sat, Apr 13, 2002 at 05:24:16PM +1000, Glenn McGrath wrote:
> > I imagine the biggest problem with this idea is getting distributions
> > to use it, which would probably require modification of their archive
> > and package managment tools.
> 
> Actually, the biggest obstacle would be the loss of control of 
> a distribution to be able to fully test a controlled set of binaries.
> 
I dont follow, if the upstream source is in a different location to the
remaining parts of the source package (metadata/patches) the binary can
still be built and tested.

> In a sense, both Red Hat and Debian already do this (as do many others)
> in that the SRPMS or source dpkgs do include the original upstream
> source (usually) and patches made by the distribution. The binary
> release can obviously not do this.
> 

Yes, SRPMS, debian and slackware source packages have what is most likely
to be pristine upstream source, my point is that why not seperate the
common source from each of these into one common pool instead of having
the same source in over a dozen locations on most free software mirrors

> I agree in philosophy, but might argue that in practice, distributions
> already do this for the majority of packages now. It isn't that hard
> to see what a distribution has changed on any given piece of software,
> as patches are available.
> 
Well, with debian there are situations where the "upstream source" has
been modified, debian only handles .tar.gz, so if upstream source is in
.tar.bz2, or if the package maintainer wants to handle multiple patches
seperatley then the real upstream source is hiden inside a false upstream
source package, i dont know how pure SRPM and slackware sources are.

> Don't underestimate the need for controlled testing of a full binary
> distribution, something which a source-only distribution can
> unfortunately not accomplish. (Not that I don't think there is use for
> these, but there are certainly big disadvantages.)
> 

Im not proposing a new distribution as such, it would be just something
that existing distributions could use as the mirror for the upstream
source of their packages. 



Glenn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://spi-inc.org/pipermail/spi-general/attachments/20020413/533470c7/attachment.pgp


More information about the Spi-general mailing list