Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

http://bugs.sourcemage.org/show_bug.cgi?id=7703


acedit AT armory.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Additional Comments From acedit AT armory.com  2005-02-10 21:25 -------
Im going to close this as fixed, but first I'll do a brain-dump to convince
myself that this is sufficiently fixed. I wont be offended if someone wants to
prove me wrong.

In the old system there were several potential points at which tarballs could
get broken:
tarballs generation on smee -> smee's tmp dir
smee's tmp dir -> sgl/dists
sgl/dists -> smee's ftp share
smee's ftp share -> mirror's tmp dir
mirror's tmp dir -> mirror's http share
mirror's http share -> user's local disk

The new system looks like this
tarballs generation on the mirror -> mirror tmp dir
mirror tmp dir -> mirror http share
mirror http share -> user local disk

the main cause of breakage with sorcery tarballs was the trip from the 
perforce
server to the main mirror, since we've removed that hop and build the tarballs
on the mirror that part shouldnt be a problem anymore. The other part that was
likely to break was the download from the mirror to the user's box, with gpg
checking enabled that part is verified and the user will know if theres a
problem before they install.

So the only part that can really go wrong now is the tarball generation part. 
If
we /generate/ a bad tarball. Gpg can't save us here.

The script that builds sorcery tarballs is pretty simple and stupid (i think 
its
simpler than the script that used to run on the perforce server) so Im not 
going
to rule out tarballs getting built incorrectly, but i'll say its sufficiently
unlikely (havent had a bad one yet). Barring complete failure of tar to work
properly I cant see it happening. Its to the point where any script we write 
to
verify the tarball somehow will be bigger and more likely to fail than the 
build
script, so its not really worth the effort IMO.

But maybe a future goal when the unit tests are sufficiently done they can get
run on the generated tarball before posting it for download "just in case" it
gets built wrong, but thats not really necessary to call this bug fixed IMO.

Of course, Im prepared to be proven wrong when we generate a bad tarball.

-- 
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.