> Could .gz or .bz2 be used instead? I think those are stable.
Either of those would be great. Typically, bzip2 wins on compression and gzip
on speed. In this case, bzip2 is probably a good choice.
In the off chance it's helpful, here are the standard command line invocations
on unix for creating bzip2 and gzip archives of some directory:
$ tar -cjf new-bzip2-archive.tar.bz2 path/to/contents
$ tar -czf new-gzip-archive.tar.gz path/to/contents
The -c flag "creates" an archive, the -j and -z flags compress with bzip2
and gzip respectively. The -f flag specifies the archive path.
And just in case the use of tar seems mysterious, the reason we need it here is
because bzip2 and gzip are simply compression formats, meaning they only work
on single files. So we use tar to first "archive" a collection of paths into a
single file and compress the result. This is a common enough operation that tar
simply provides convenience flags that do the wrapping for us.
Thank you for caring about us package maintainers!
Norman Megill <[email protected]> wrote:
> Nothing was changed inside the zip file between the dates you mention.
>
> The zip file is recreated from source about once a day from the command:
> zip -9 downloads/metamath-program.zip metamath/*.c metamath/*.h \
> metamath/metamath.exe metamath/configure.ac metamath/Makefile.am \
> metamath/metamath.1
>
> So the zip command apparently does not produce an identical compressed file
> even if the contents are the same.
>
> Could .gz or .bz2 be used instead? I think those are stable.
>
> Norm
>
>
> The problem may be that the zip program
>
> On Friday, January 31, 2020 at 10:58:51 PM UTC-5, heiphohmia wrote:
> >
> > This is part of a larger discussion happening at [1].
> >
> > It appears that the metamath-program.zip URL[0] points to a non-static
> > archive.
> > Sadly, this is preventing me from packaging metamath for my Linux
> > distribution.
> >
> > Just for the sake of clarity, below are the SHA-256 sums of the archive
> > retrieved on the corresponding dates:
> >
> > - 2020 Jan 28
> > 75fe8e83c4fde2104e24e38da8480b512df3dff40d46e5d40e038bd7a73557de
> > - 2020 Feb 01
> > 084bb35600823c8c6db4375203d239c5d05df4488ce035fd05da8918dea70261
> >
> > Unfortunately, the newer archive overwrote the old on my machine, so I
> > cannot
> > compare contents. From a cursory inspection, however, it looks how I
> > remember.
> > My suspicion is that, perhaps as part of a larger automated process, the
> > zip
> > metadata is getting refreshed.
> >
> > Is there a way we could offer static, versioned, archives of the
> > standalone
> > executable source? One common option for this would be to let GitHub host
> > them
> > as "releases" for the metamath/metamath-exe repository. Though I have not
> > tried
> > myself, the creation process looks quite easy:
> >
> >
> > https://help.github.com/en/github/administering-a-repository/creating-releases
> >
> >
> > Does it seem reasonable to make this happen, some way or another?
> >
> >
> > [0]:http://us2.metamath.org/downloads/metamath-program.zip
> > [1]:
> > https://groups.google.com/forum/#!msg/metamath/z2kKJYgnz-g/Z4mVlHVkAwAJ
--
You received this message because you are subscribed to the Google Groups
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/metamath/2IHDHNYHHXN2R.3E1MAFGV7W4IX%40wilsonb.com.
