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/ [email protected] 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" <[email protected]> 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 [email protected]. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/metamath/E1iiRY9-0007E6-Vq%40rmmprod07.runbox. ----- End forwarded message ----- -- 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/20QYJ5GGNRNQS.3NMAZTLZD9TDI%40wilsonb.com.
signature.asc
Description: PGP signature
