On Mon, 27 Sep 2004 19:24:04 +0900, Eivind Eklund <eeklund / gmail.com> wrote:
> On Mon, 27 Sep 2004 01:56:34 +0900, Austin Ziegler <halostatue / gmail.com> wrote:
> > Thank you, Mauricio. Question for people interested in packaging:
> > since this is merely a packaging error (not affecting ANY files in the
> > released code), should this update be a separate version or should it
> > be a replace-in--place? (It only affects .tar.gz files).
> 
> I am of the distinct opinion that ANY change to the release should
> result in a bump.  A number of the repackaging systems out there use
> one way/secure hashes (SHA1, MD5 - do not use for new apps, et al) to
> verify that the files involved in a release are the same as the ones
> the person doing packaging saw.  If you change the release in any way,
> you'll invalidate this, and waste the time of the people that use
> these systems, as they end up getting your modified tarballs and start
> looking through diffs etc to see if you have been attacked and gotten
> a trojan.
> 
> At least for FreeBSD ports, you'll get a fallback to our mirrors if
> the file isn't there, so there is little problem with just removing a
> wrong release.
> 
> So: New release numbering for ANY change.

Yet ... Mauricio suggested that this is little different than the
.tar.gz being corrupted on upload.

I am working on something that makes it easy to deal with this, but
right now, doing anything other than uploading the corrected .tar.gz
would engender a lot more work than I have time to do. Later, it'll be
a single command. But for now, I think that for *this* change
(Archive::Tar::Minitar 0.5.1) I will be replacing the corrupted
tarfile.

-austin
-- 
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca
: as of this email, I have [ 6 ] Gmail invitations