Re: Rebuilding a package after removing a build step

[Kaelyn]

On Monday, September 23rd, 2024 at 11:17 AM, Suhail Singh 
<suhailsingh247@gmail.com> wrote:

> 
> 
> Vagrant Cascadian vagrant@debian.org writes:
> 
> > Rather than picking an arbitrary incremental number, I have in the past
> > used something based on the results from git describe... e.g. in my
> > current checkout of guix:
> > 
> > $ git describe --match=v1.4'*'
> > v1.4.0-142685-gfc059c66cf
> > 
> > e.g. 142685 commits past v1.4.0, with the commit fc059c66cf
> > 
> > That should usually end up in the correct order, although sometimes
> > there are surprises. For example, I had to specify --match otherwise it
> > picked v1.3.0 for some inscrutible git merge-ordering reason.
> 
> 
> That seems like a useful and fairly generally applicable strategy. Any
> reason as to why something like that (which allows for additional
> optional arguments such as "--match-v1.4'*'") shouldn't be used as the
> default (as opposed to manual revision numbers)?

There are a few problems with using that as the default:
* Generating that version number requires the git source repository; a package 
definition requires a fixed version number that can be computed without ever 
downloading the source code, since it is part of the package metadata (though 
such a strategy could potentially be used by e.g. "guix refresh -u" though that 
would require a consistent way of setting the revision in the package 
definition such that the tool knows what string to change).
* Using something like "git describe" to compute the revision would either be 
specific to packages which are built from git checkouts (i.e. built into the 
git-version function) or recipes for obtaining similar output would have to be 
written for the other version control systems for which support is desired. 
Closely related (but optional if the actual value of the revision is treated 
more loosely) is that some packages would need the "--match" flag to generate 
revision numbers from the correct point and the match expression would have to 
be updated when the "base" version for the revision counting changes.
* Within git repos, "git describe" only works if there are (annotated) tags for 
"git describe" to base the revision number on. If the source repo doesn't use 
tags, the approach won't work and manual revision numbers would still be 
needed. Likewise, if the repo doesn't use annotated tags or uses annotated tags 
for purposes other than tagging official releases, the chosen tag used for the 
revision (even at a given commit, if an older commit is given a new tag) may 
not be consistent without using a sufficiently specific "--match" flag.

I also want to say that the above points are primarily about automatically 
using "git describe" to dynamically generate a revision. I do not want to rule 
out or discourage ideas for ways to make use of "git describe" more convenient 
as a source of truth when determining what value to use for the revision. I 
think it could be quite useful especially for updating packages or doing local 
development.

Cheers,
Kaelyn

> 
> --
> Suhail