metamath-program.zip has never been on the home page. It was originally added so Travis could download just the program without being slowed down by unnecessarily including the .mm files, and it is still used for that. Later it also become used for Linux distribution, and the compiled Windows version was removed. Later I took it out of the site build script because the sha256 changed each time it was regenerated, so now I regenerate it by hand only whenever a new version of the metamath program is released.
However, I'm not really competent to decide what is needed. If GitHub can take care of it that would be great, and I could then put it back into the site build script for Travis use. It's currently one more thing I have to remember to do after updating the program (and I forgot to regenerate it last time which caused some problems but hopefully will remember in the future). Norm On Monday, April 27, 2020 at 3:11:43 AM UTC-4, heiphohmia wrote: > > Hello Norm, > > This is in reply to > > > https://groups.google.com/forum/#!searchin/metamath/Packaging$20Metamath$20for$20Linux%7Csort:date/metamath/z2kKJYgnz-g/xmRVy0KhCQAJ > > > For whatever reason my direct replies to the above seem to be falling into > Google's black hole, so I am sending this as a new thread: > > > At the risk of summoning a zombie from long dead discussion, let me bring > this > issue up again. > > I am attemtping to package metamath again, this time for Guix[0], and am > hitting a snag. The problem is that the `metamath-program.zip' link points > to a > non-constant source, i.e. it changes every time metamath gets a version > update. > > Anyway, instead of blasting you with the nitty-gritty details this time, I > have > a proposal. How about we git rid of `metamath-program.zip' altogether > (which > URL I can no longer find on the home page, anyway) and instead let GitHub > take > care of it for us? > > Previously, at the 0.181 update Giovanni asked you to incant the > following: > > git commit -m'Release version 0.181.' > git tag v0.181 > git push > git push --tags > > It looks like this automatically created zip and tar archives for us on > the > "release" page (https://github.com/metamath/metamath-exe/releases) with > all the > properties that keep us package maintainers happy. Would it be reasonable > to > include this git workflow into your process/script for version updates? > > > On a related note, the current repository ends up generating broken > `install' > and `dist' make targets. The fix is quite simple, for which I submitted a > pull > request: https://github.com/metamath/metamath-exe/pull/6. It simply > removes the > refereces to the missing `*.mm' databases. Is this a reasonable thing to > merge? > > Cheers! > > > [0]:https://www.gnu.org/software/guix/ > > heiphohmia <heiphoh...@wilsonb.com> wrote: > > Thank you, Dr. Wheeler, for sharing all this context with us. > > > > For whatever it is worth, I am personally, quite happy with the URL that > Norm > > made public for us. It makes packaging *possible* which is huge. > > > > FL's suggestions seem reasonable to me if the goal is to minimize > friction for > > package maintainers; however, if this poses problems/inconvenience > upstream as > > you suggest, then how about compromise with a README in the > > metamath-program.zip for now? At a bare minimim, it might be nice to > explain > > the (mildly non-standard) compilation procedure, as well as link to the > set.mm > > repo. > > > > I am currently holding off on submitting a packing to Void Linux until > it > > becomes clear what exactly source bundle we want Metamath to provide. > > > > As a side note, what are thoughts on the idea of also providing a shell > script > > wrapper "codifies" things like downloading, updating, listing etc the > *.mm > > databases? This might make packaging more of a simple turn-key solution, > so > > that metamath installs files to more standard filesystem locations. I > certainly > > would not mind writing such a script, which would likely turn out a lot > like > > the one I shared in a previous post here. > > > > Cheers, > > > > > > "David A. Wheeler" wrote: > > > > > David A. Wheeler: > > > > > I think we can revisit and improve things, but whatever build and > > > > > distribution process changes are made needs to be something that > Norm is > > > > > willing to accept. Norm has limited time and his own preferences. > > > > > > On Fri, 20 Dec 2019 04:52:22 -0800 (PST), "'fl' via Metamath": > > > > Why does he let people waste their time talking if he knows he > doesn't want > > > > it ? > > > > > > It's not a waste of time. > > > > > > Norm is happy to let *other* people use the autotools. After all, > > > using the autotools typically produces a Metamath executable with > significantly > > > higher performance for certain operations. > > > > > > However, Norm prefers using his own tools & doesn't use the autotools > *himself*, > > > at least not at this time. > > > > > > So the compromise has been for Norm to use whatever tools he wants, > and Norm > > > simply includes various autotools files like configure.ac in the > Metamath release. > > > That makes it *possible* for recipients to use the autotools. > > > Since Norm doesn't run the autotools himself, recipients can't be > guaranteed that the > > > "configure" file is up-to-date. Instead, recipients who want to use > the autotools > > > have to run "autoreconf" themselves to *generate* the configure file, > and then use > > > the configure file as usual to do the rest of the build. > > > > > > Yes, this is more steps than usual. However, > > > this is not completely unknown. You also have to do this extra step > with some > > > GNU packages if you download a development version instead of an > actual release. > > > It is unusual for *released* software. Typically *releases* of > software that > > > support the autotools include a pre-generated configure file that was > created by > > > the autotools as part of the process for creating a release. > > > But doing that would require Norm to install & run the autotools. > > > Norm might be willing to do that now, but he didn't want to do that in > > > the past & that change is up to him. > > > > > > I'd be happy to modify the autotools files (e.g., configure.ac) to > change things. > > > I just got back from a trip to Florida, & Christmas is coming, but > once things get > > > a little quieter I'd be happy to help. I would just need to know what > changes > > > need to be made. > > > > > > --- David A. Wheeler > > -- 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 metamath+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/metamath/9c06f0ec-d59a-4c3e-8a08-cca82e21548b%40googlegroups.com.
