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
