Your message dated Tue, 21 Dec 2010 07:32:22 +1030
with message-id <[email protected]>
and subject line Re: Bug#607572: git-buildpackage compatible tagging as an
option
has caused the Debian Bug report #607572,
regarding git-buildpackage compatible tagging as an option
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
607572: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607572
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: gitpkg
Version: 0.17
Hi!
Right now g-b-p compatible tagging requires editing the source code of
git-debimport.
I'd like to have it as an option, without requiring to clone the scripts
repository and change it, because it kind of defeats the purpose of
having a package.
I can write a patch for it, if you will consider it, but now, I think,
we've git too many options to fit in the usage line. What to do :-) ?
Thanks!
--
Sincerely yours,
Yury V. Zaytsev
--- End Message ---
--- Begin Message ---
On Sun, Dec 19, 2010 at 10:17:02PM +0100, Yury V. Zaytsev wrote:
> Package: gitpkg
> Version: 0.17
>
> Hi!
>
> Right now g-b-p compatible tagging requires editing the source code of
> git-debimport.
>
> I'd like to have it as an option, without requiring to clone the scripts
> repository and change it, because it kind of defeats the purpose of
> having a package.
You don't need to clone the repository, you just need to uncomment 2 lines
in a shell script.
> I can write a patch for it, if you will consider it, but now, I think,
> we've git too many options to fit in the usage line. What to do :-) ?
The original git-di was basically a quick hack to solve the problem of
most git-converters not really working very well on most package repos.
I'd originally thought it would be useful for a couple of years, then
everyone who was going to would have converted their repos and we'd get
rid of it -- but it's kind of grown since then, and with the option to
import packages from snapshot.d.o, does now seem to have a longer term
future ahead of it. As you've seen though, not all historical packages
are really in a state where a fully automated import can work without
some manual intervention, so I don't really think some manual tweaking
from time to time for a particular use is going to be totally out of
the ordinary for this task.
I'd like to cover as many cases as we can out of the box, but I don't
think we can ever totally cover every historical anomaly in every package
with it without some manual tweaking being needed occasionally.
Re the tags then, frankly, I think the g-b-p convention is a horrible
arbitrary NIH scheme that shouldn't be encouraged at all. If you are
cloning upstream from upstream, no sane upstream is going to tag their
releases upstream/foo -- so we shouldn't either. People who can't tell
the difference between a version with a debian version in it from one
that doesn't are probably already in deep trouble anyhow, so adding the
extra goop adds no information, just more to type when you want to do
an export.
$ gitpkg v0.1-1 v0.1
lacks nothing over
$ gitpkg debian/0.1-1 upstream/0.1
for information. It's just less clutter when browsing the repo, less
to type when exporting, doesn't look like something random that debian
invented, and means you don't have to change your convention when your
upstream finally moves to git themselves and you start working off of
their repo (which is clearly the best endgame to aim for).
If you really want to use g-b-p instead of gitpkg, I believe it can be
told to use a sane tag format anyhow. So I think I'd rather encourage
them to make that the default there instead of encouraging people to
make more repos with a bad convention. I don't really see it as a
problem that people who want to make more work for themselves forever
more in the future would need to make an initial investment of deleting
two #'s in the script to ante in.
Cheers,
Ron
--- End Message ---
