Bug#871950: git: Please keep packaging git archimport
On 15/08/2017 21:30, Jonathan Nieder wrote: That makes sense. I am going to try to move git-archimport.perl to contrib/ upstream and package it in either /usr/share/doc/git/contrib/ or /usr/share/git-core/contrib/ like other contrib scripts. I'll include instructions in /usr/share/doc/git/README.Debian for using it. Thanks for the patient explanations. Sincerely, Jonathan This seems an excellent solution to me. It's me to thank you! for your attention in understanding users' needs (and even lazyness!). Best regards, Sergio
Bug#871950: git: Please keep packaging git archimport
Hi Sergio, Sergio Callegari wrote: > 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. [...] > Jonathan Nieder wrote: >> 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. That makes sense. I am going to try to move git-archimport.perl to contrib/ upstream and package it in either /usr/share/doc/git/contrib/ or /usr/share/git-core/contrib/ like other contrib scripts. I'll include instructions in /usr/share/doc/git/README.Debian for using it. Thanks for the patient explanations. Sincerely, Jonathan
Bug#871950: git: Please keep packaging git archimport
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
Bug#871950: git: Please keep packaging git archimport
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
Bug#871950: git: Please keep packaging git archimport
Package: git Version: 1:2.11.0-3+deb9u1 Severity: normal Dear Maintainer, 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. Should tla have security issues (which we do not know, since the issue seems to be merely that it has not received patches in the last years), the git helper alone is totally innocuous. With the helper in git, to recover data from backups that may include tla archives, it can be enough to manually build tla and run it in a "controlled" environment. Without the helper in git, one needs to locally rebuild git too, duplicating stuff that is already in the official packages. 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. Please, also consider the timing of the decision. You say that archimport will disappear from 2019, but following your decision, it is disappearing right now from ubuntu. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 4.9.0-3-marvell Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages git depends on: ii dpkg 1.18.24 ii git-man 1:2.11.0-3+deb9u1 ii libc62.24-11+deb9u1 ii libcurl3-gnutls 7.52.1-5 ii liberror-perl0.17024-1 ii libexpat12.2.0-2+deb9u1 ii libpcre3 2:8.39-3 ii perl 5.24.1-3+deb9u1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages git recommends: ii less 481-2.1 ii openssh-client [ssh-client] 1:7.4p1-10+deb9u1 ii patch2.7.5-1+b2 ii rsync3.1.2-1 Versions of packages git suggests: ii gettext-base 0.19.8.1-2 pn git-arch pn git-cvs pn git-daemon-run | git-daemon-sysvinit pn git-doc pn git-el pn git-email pn git-gui pn git-mediawiki pn git-svn pn gitk pn gitweb -- no debconf information
