On 2025-05-07 12:10:00, Tony Luo wrote: > Hi all, > > What is the idiomatic way to package a specific revision of an external > package or rather update an existing external package to a specific > revision? For context, I am working on a PR to bump Singular to commit > 0a4bc0e
Ultimately, you should probably just wait for the next Singular release and then update to that. It's much better if sage-the-distro and sage on linux/conda/homebrew/etc. all act the same way, and it's unlikely that everyone involved in the packaging effort is going to update to the same snapshot. But to answer the larger question, updating to a specific revision (rather than a release) will be a little difficult in this case because Singular uses autotools, and typically the upstream developers have to perform some steps to generate ./configure and the associated Makefile.in files. You could do that yourself, but then you would have to host your release somewhere, and then -- at least in theory -- someone would have to verify that you haven't backdoored the package. If possible, it's better to just patch the existing release. You can do that by dropping a patch into the "patches" directory of the spkg (see pari for an example). But even this is discouraged if it changes the behavior of sage because, assuming you add a test case for whatever bug is fixed, everyone packaging sage then has to quickly adopt your patch or else the tests begin to fail. In this instance, adding a patch and then *not* adding a test could be a good compromise. (You can obtain a patch by sticking ".patch" on the end of the github commit URL.) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/aBu3cXwtgi5_boE2%40mertle.
