Dear Jonathan,
thank you for your email. Indeed, I should have checked that the archimport
script could be installed without recompiling the whole of git, being a perl
script rather than compiled C.
My problem is in fact mostly an ubuntu related problem. Even if debian planned
retiring tla and archimport by 2019, by "reusing" debian packages, ubuntu is
already shipping through its git-team ppa an up to date version of git without
archimport even if it's going to still package tla for at least two more releases.
That would make the package no longer suitable for Debian. Debian
packages declare their dependencies and their dependencies must be
present in Debian. That said, such a package could exist in contrib.
I totally understand. Still I think it would appreciable if scripts from the git
sources that can no longer be shipped in forms that make them installed "as
executable" because their dependencies cannot be satisfied could still be
delivered somehow, to avoid shipping a "reduced" git.
an you say more about
how you would use it? E.g. if you would install arch from source, why
wouldn't you be able to install the git-archimport.perl script from
source as well?
My fault. Initially, I thought that the archimport was something that needed git
to be recompiled, while now I see that it is a script that I can simply drop
somewhere and make accessible by git via an environment variable.
For tla, my hope is that the tla deb from debian stretch or ubuntu xenial, zesty
or artful can remain installable for a long time in future distros, since its
dependencies seem to be rather minimal.
If you would use it to recover tla data from backups,
why not convert that tla data to git format today
Because backup contain very obsolete stuff, are messed and are used "lazily".
Only when something requires the history of some old stuff to be checked to
understand its genesis, and there is no git repo, one gets the courage to seek
and extract the corresponding tla archive from the backup and convert it to git.
Which is the reason why I have this stuff around so many years after something
way better than tla came around. Unfortunately, I understand that laziness is
not a very nice explanation.
Best regards,
Sergio
On 15/08/2017 03:31, Jonathan Nieder wrote:
Hi Sergio,
Sergio wrote:
please reconsider the decision in #866059 to stop packaging git-archimport.
It makes it unnecessary cumbersome to recover tla data from backups
and deprives git from one of the components that its upstream
maintainers consider worthwhile distributing.
Even if tla is not shipped in debian, I see no reason not to provide the
archimport helper in git.
Thanks for writing.
I would agree with you if "git archimport" were a tool that can run
independently of tla. For an example of that kind of tool, see the
vcs-svn/ directory in git's source: it works with an svn-format dump
file without requiring any part of subversion to be available on the
local machine.
Unfortunately, "git archimport" requires tla to function, in
fundamental ways. As the script explains:
# The basic idea is to walk the output of tla abrowse,
# fetch the changesets and apply them.
Without the tla command, this script does not function at all.
[...]
I think that, at most, the helper should be patched to not depend on tla and
provide an informative notice if tla is not in the system.
That would make the package no longer suitable for Debian. Debian
packages declare their dependencies and their dependencies must be
present in Debian. That said, such a package could exist in contrib.
Packaging it that way is an interesting idea. Can you say more about
how you would use it? E.g. if you would install arch from source, why
wouldn't you be able to install the git-archimport.perl script from
source as well? If you would use it to recover tla data from backups,
why not convert that tla data to git format today so that you can
restore it from backups using ordinary git?
Thanks,
Jonathan
