Thank you for the detailed response. I actually tried to patch the existing release with the generated ".patch" file from the GitHub commit URL prior to just bumping the source. A naive attempt fails (as expected) since there is quite a large set of changes between the commit and the current packaged release. As I am not familiar with the Singular codebase, I haven't attempted to trace out the affected files/dependencies for the fix back to v4.4.0. Admittedly this is something out of my depth at the moment.
Regarding the use of autotools, would generating ./configure during the build with a spkg-src script be acceptable here or would you still recommend waiting until the next Singular release? My main concern here is that the Singular bug fixed in the aforementioned commit is nonfatal but nonetheless corrupt the state of objects on the sage side of the interface (see the issue for more details). I don't know how severe this issue is on the grand scale of things but it seems less than ideal to maintain the status quo until the next Singular release. If waiting for the next Singular release is better, would a PR that checks the condition that triggers the bug and aborts the computation be helpful in the meantime? Of course, the changes introduced would have to be reverted when actually bumping Singular. On Wednesday, May 7, 2025 at 3:41:43 PM UTC-4 Michael Orlitzky wrote: > 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/b9699052-099c-479c-b0b2-e7bca14a4123n%40googlegroups.com.
