Re: Upstreams with "official" tarballs differing from their git
Hi,
Le lundi 17 février 2025 à 10:07 +0100, Julien Plissonneau Duquène a
écrit :
> Le 2025-02-16 21:03, Julien Puydt a écrit :
> >
> > - the previous version used %%VERSION_NUM%% in only three places,
> > the
> > new one uses it more, so it broke my previous hack -- ;
>
> As a matter of best practices, this should probably be defined in a
> single place and not "hardcoded" multiple times with templating.
Yes. Most upstream have little clue on what a best practice is, and
need to be explained at length. That's part of the job of a DD...
> > - there are other things than the substitutions done by dune when
> > compiling the package, which do not break the build, but will break
> > some depending packages later on with strange and misleading
> > errors.
>
> Do you mean here that using the "official" tbz source tarballs for
> builds outside of a git tree will result in these errors? If so,
> that's a serious upstream build tool issue IMO.
No, I mean the build tool takes the git repo with the .git/ directory,
and gives a tarball without .git/ where substitutions have been made
(those can be recognized because they look like %%FOO_BAR%%) *and* some
code added in various places (those can't be recognized beforehand).
Their .tbz is working nicely -- but it isn't source anymore!
> > As mentioned somewhere in the thread I proposed to dune upstream a
> > simple mechanism to bypass this git reliance issue, which will make
> > packaging much cleaner.
>
> That's probably the way to go here. I would also suggest modifying
> dune-release so the git release tags end up with the substitutions
> already applied, to make it possible to simply export them and build
> them outside of a git tree.
I think the way to go is the one I proposed in my upstream bug report
( https://github.com/ocaml/dune/issues/11484 )
and which Stéphane Glondu proposed a PR for
( https://github.com/ocaml/dune/pull/11485 ). It hasn't been accepted
yet, but there's hope.
Cheers,
J.Puydt
Reply to: