[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Preferred git branch structure when upstream moves from tarballs to git [and 1 more messages]



Holger Levsen writes ("Re: Preferred git branch structure when upstream moves from tarballs to git [and 1 more messages]"):
> On Wed, May 08, 2019 at 04:14:00PM +0100, Ian Jackson wrote:
> 
>  * Debian should provide source code as git branches which:
>       - can be built using a standard set of runes
>       - will produce the same binaries as official Debian ones 
>       - can be reliably located
>       - can be easily modified (using standard git commands)
>       - contain the git histories we are actually using ourselves
> 
> There is only one way to do this.  It is `dgit push[-source]'.
> Vcs-Git and Salsa do not provide this. 
> 
> ---end quote---
> 
> and I'm not sure I agree this is true, to me Vcs-Git and Salsa do provide all
> of this, *if* Vcs-Git is set.

No, sadly not.

   - can be built using a standard set of runes

This is not true of Vcs-Git because the format of the Vcs-Git
repository is not standardised.

   - will produce the same binaries as official Debian ones 

This is not true of Vcs-Git because it is not trivial (or even, in the
general case, systematically possible) to find the right git tags
corresponding to a particular upload.  DEP-14 does help here but not
everyone agrees with it: eg, git-dpm has slightly nonstandard version
mangling and its maintainer has resisted changing; packaging-only
monorepos cannot use DEP-14 tags because DEP-14 tags aren't
package-qualified.

debcheckout *certainly* doesn't do this.  It just gives you the
current master which may not have been uploaded anywhere.

   - can be reliably located

Vcs-Git does help find the repo, but finding the right branch/commit
is difficult (see above).  Also, Vcs-Git gives wrong answers if there
was an upload (eg an NMU) which was not pushed to salsa.  If you use
debcheckout you might miss an important security update this way!

   - can be easily modified (using standard git commands)

This is not true of Vcs-Git because of the repository format problem.
The most common tree format is patches-unapplied, which does not meet
this requirement.  git-grep does not work properly; git-blame does not
work properly; git-merge does not work properly; git-cherry-pick does
not work properly. etc. etc.

   - contain the git histories we are actually using ourselves

Vcs-Git does meet this requirement.

> So, IOW, I can see problems with individual packages here but not with the
> general workflow/tool of using vcs-git: and debcheckout.

See also my response to some similar points raised by Simon McVittie:

  https://lists.debian.org/debian-devel/2019/05/msg00085.html

Regards,
Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.


Reply to: