Re: making dput a wrapper around git
On 18/11/14 15:23, Thorsten Glaser wrote:
> On Tue, 18 Nov 2014, Daniel Pocock wrote:
>
>> That is not a Git-specific issue, it is a general issue with source-only
>> uploads. If source-only uploads become the norm then signed tags should
>> be the same as source packages shouldn't they?
> Absolutely not! (Hint: .orig.tar.gz, often several. And other
> things. I don’t want to go into this in detail.)
>
>
> Besides: dput is not the tool to push source-only uploads into.
>
> dput is *also* used by people creating binary packages (and,
> quite possibly, builders, although Debian buildd network uses
> dupload) to publish them by their *.changes file into the target
> repository.
>
> dput is *also* used with a stanza like this…
>
> [i]
> method = local
> incoming = /var/cache/pbuilder/result/incoming
> allowed_distributions = .*
>
> … to copy the result of cowbuilder to a staging directory,
> or something else like that.
>
> T̲h̲a̲t̲’s my point here.
>From that perspective, I completely agree, some of those other workflows
are not in scope of what I had in mind and if dput did support some Git
operations it should not deprecate other use cases.
One of the problems with a VCS right now though is the order of events
required to make a tag. If I tag and then upload and my upload is
rejected for any reason then the tag is not valid.
Currently, I don't tag in my VCS until I get the email confirming my
upload was accepted. For uploads that went through NEW, that could be 2
months later. When using signed tags, I much prefer to sign the tag
immediately, not after 2 months.
There are other solutions to problems like this however. For example,
maybe the changes file could include some optional new header with the
VCS commit ID used to build the source package? When I sign the changes
file, it would be a permanent record of which commit I was on when
building. When the package is accepted I could then read the commit ID
from the changes file and use it as an argument to git tag.
Reply to: