Hi,
Le 15/02/2025 à 10:08, Julien Puydt a écrit :
Usually, projects using this trick publish tarballs with
substitutions
applied:
https://github.com/LPCIC/elpi/releases/tag/v2.0.7
(here, elpi-2.0.7.tbz).
I realize my previous email was a bit short: I was wondering if this
.tbz still source code because in the autotools world, package sources
come with configure scripts ready to run, but the good practice in
Debian is to regenerate those from configure.ac.
Well, we enter a philosophical debate that is not specific to OCaml and
probably should be discussed elsewhere... Adding debian-devel to get
more opinions.
Summary to other debian-devel readers: we are facing some upstreams that
publish "official" tarballs that differ from what is in their git. The
differences may include: variable substitutions, generated files... I
guess this is pretty common (cf. autotools). Moreover, the build system
behaves differently if it is called from git or not, or from extracted
official tarballs or not.
IMHO, traditionnaly, "source code" from Debian point of view is whatever
upstream releases as "official" tarballs (i.e. elpi-2.0.7.tbz), which
may differ from what is in upstream git (i.e. v2.0.7.tar.gz). What makes
me think that is the special care that is taken in keeping upstream
tarballs pristine (with their signatures...).
Some may consider that this Debian notion of "source code" differs from
the GNU "preferred form of modification", which would rather be what is
in upstream git... or is it? In Debian, we "modify" upstreams by
applying patches on top of them, so I argue that using "official"
tarballs is fine as long as patches used in Debian packaging apply on
upstream git as well.
Anyway, I do think the "GNU" source should be recoverable from the
"Debian" source. Technically, this is usually not the case with variable
substitutions, but IMHO it's acceptable to use the substituted sources
most of the time.
On the other hand, insisting on using upstream VCS contents can lead to
ugly hacks in Debian packaging, such as what you are describing. I must
admit I usually use "official" tarballs to avoid these hacks (and maybe
a little out of laziness).
I fixed the elpi package by using something a bit hackish: I added git
as dep, and if I don't see a .git in the build directory, I create one!
Here is what the execute_before_dh_auto_build target does:
if test -f .git; then \
@echo "Found .git, ok"; \
else \
touch .false_git; \
git init --initial-branch=main; \
git config user.email "f...@bar.baz"; \
git config user.name "Foo Bar"; \
git add dune; \
git commit -m foo; \
git tag -a v$(DEB_VERSION_UPSTREAM) -m foo; \
fi
and here is what the execute_after_dh_auto_clean does:
if test -f .false_git; then \
rm -rf .false_git .git; \
fi
This is ugliness to paper over ugliness. Please do not!
My approach to this specific problem would be to add to dune the
possibility to use some configuration file (or environment variables) as
input for the substitutions, instead of directly querying the VCS. This
configuration could then be set up as part of the Debian packaging.
I suppose dh's ocaml_dune building tool could do that trick itself
(using debian/fake_dot_git instead of .false_git, better
user.email/user.name...), and that would make sure we don't break.
In case it is not clear: I will oppose this ending up in dh-ocaml.
However, dh-ocaml would be the right place to add support for the
approach I outlined above.
What do you think about the topic?
My e-mail is very opinionated, I would really like to hear other opinions.
Cheers,
--
Stéphane
