Le dimanche 16 février 2025 à 14:51 +0000, Colin Watson a écrit : > > This is a false dichotomy, though. It's perfectly possible to use > both > in conjunction with each other, by importing a tarball on top of an > upstream git tag so that the differences between them are represented > by > a git commit. There are various tools in Debian to help with this. >
Actually, it's a bit more complex. If you use autotools, you start with configure.ac and .in files. If upstream prepared the tree (as they generally do), you also get a libtool/configure, etc. From this, you can run ./configure && make && make install ; that will do substitutions in the .in files. And if you want to start anew, you can use autoconf/autoheader/whatever to re- create the configure/libtool script and then ./configure && make && make install. The .in files are at hand to start again, we have the developer sources and more. So at this point, no real dichotomy on what you use as source. But in the case at hand, the 'dune' tool to configure&compile the 'elpi' software (and others), things work differently. If you go here: https://github.com/LPCIC/elpi/tags and get the .tar.gz, you'll get an extract of the git tree, which lacks the versioning information, but has the %%VERSION_NUM%% (and others) ready for substitution. That's what I want to use. So my problem was to force-feed the missing git information to dune so it can actually makes those substitutions. Stéphane's suggestion was to use the .tbz taken here: https://github.com/LPCIC/elpi/releases/tag/v2.0.7 where the substitution have already been done. But contrary to the autotools situation, there's no going back: the substitutions are not just ready to be applied, they are made, done and gone! If I wanted to re-version as 2.0.7-debian or whatever, that isn't a possibility: %%VERSION_NUM%% doesn't appear anymore in the tree. The versioning information is soldered all other the place. So here there is a clear dichotomy: depending on the tarball, you don't have the same. I'm hopeful dune upstream will accept my proposition and provide a force-feeding mechanism to use the real source tree painlessly, because I really think considering this .tbz a source tarball is incorrect. I have always considered the true way to know if you have the source of a package is: imagine you're stuck somewhere with a Debian mirror and no external link. Could you take over the development of the package at hand? Cheers, J.Puydt
