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 Thu, May 09, 2019 at 01:46:19PM +0100, Ian Jackson wrote:
> > debcheckout *certainly* doesn't do this. It just gives you the
> > current master which may not have been uploaded anywhere.
>
> nope:
>
> $ debcheckout munin
> declared git repository at https://salsa.debian.org/debian/munin.git -b debian
> git clone https://salsa.debian.org/debian/munin.git -b debian munin ...
> [...]
Sorry, I was speaking loosely.
I meant it gives you the current head of the maintainer(s)' main
Debian sid packaging branch. Which may be (and often is) ahead of the
archive, because things have been pushed to it and not uploaded yet.
Ian.
--
Ian JacksonThese 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.
Re: Preferred git branch structure when upstream moves from tarballs to git [and 1 more messages]
On Thu, 2019-05-09 at 12:51 +, Holger Levsen wrote: > On Thu, May 09, 2019 at 01:46:19PM +0100, Ian Jackson wrote: > > debcheckout *certainly* doesn't do this. It just gives you the > > current master which may not have been uploaded anywhere. > > nope: > > $ debcheckout munin > declared git repository at https://salsa.debian.org/debian/munin.git > -b debian > git clone https://salsa.debian.org/debian/munin.git -b debian munin > ... > [...] I don't think that one counterexample invalidates what Ian says in the common case, it is certainly true that the most usual thing you get from debcheckout is master regardless that some (minority of) maintainers might have tried to be smarter. In any case for me it gets the `debian-experimental` branch, not really sure why and it's probably not what I expected/wanted[0]: $ debcheckout munin declared git repository at https://salsa.debian.org/debian/munin -b debian-experimental git clone https://salsa.debian.org/debian/munin -b debian-experimental munin ... Cloning into 'munin'... warning: redirecting to https://salsa.debian.org/debian/munin.git/ remote: Enumerating objects: 53812, done. remote: Counting objects: 100% (53812/53812), done. remote: Compressing objects: 100% (13784/13784), done. remote: Total 53812 (delta 37431), reused 53214 (delta 36851) Receiving objects: 100% (53812/53812), 12.51 MiB | 1.31 MiB/s, done. Resolving deltas: 100% (37431/37431), done. warning: redirecting to https://salsa.debian.org/debian/munin.git/ I think at best all this example really does is mutate Ian's "It just gives you the current master which may not have been uploaded anywhere" into "It just gives you some branch which may not have been uploaded anywhere"? Ian. [0] and the manpage doesn't seem to suggest a way to request a particular suite.
Re: Preferred git branch structure when upstream moves from tarballs to git [and 1 more messages]
On Thu, May 09, 2019 at 01:46:19PM +0100, Ian Jackson wrote: > debcheckout *certainly* doesn't do this. It just gives you the > current master which may not have been uploaded anywhere. nope: $ debcheckout munin declared git repository at https://salsa.debian.org/debian/munin.git -b debian git clone https://salsa.debian.org/debian/munin.git -b debian munin ... [...] (not replying to the other points because enotime, sorry.) -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
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 JacksonThese 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.
Re: Preferred git branch structure when upstream moves from tarballs to git [and 1 more messages]
On Wed, May 08, 2019 at 03:26:32PM +, Holger Levsen wrote: > thanks for the pointer, but I don't see the string debcheckout in that > message and vcs-git only once, where you write: > > ---begin quote--- > > >From these we can conclude: > > * 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. > > And if it's not set, it's either because the package is not in git or because > d/control is lacking information, aka the package is buggy. I think the thing you're missing is Ian's "can be reliably located" point. As you say, debcheckout works if those conditions are met, but they're very often not met. Given how long debcheckout and Vcs-Git have been around, it seems a reasonable conclusion that they're unlikely to reach 100% any time soon (and there's the long-standing problem with stale metadata in stable releases and so on that means it isn't even a ratchet, and won't be unless some as-yet-unfinished work to make it be an archive override or similar happens instead). Without wishing to speak for Ian, I think this is what he's abbreviating as "do not provide this". By contrast, "dgit clone" works regardless of whether these conditions are met, although it results in a better git history if the maintainer used "dgit push" or "dgit push-source". That does seem like an important distinction. > So, IOW, I can see problems with individual packages here but not with the > general workflow/tool of using vcs-git: and debcheckout. > > (or what am I missing?) Maybe another way to look at it is that sometimes it makes more sense to look at a problem systemically, including new tools, than by annotating thousands of source packages one by one. [FWIW: I recently started using "dgit push-source" for my uploads, partly as a result of this thread although I'd been meaning to look into it for ages. I've filed a couple of bugs and been confused about one or two things that Ian has kindly helped me with, but by and large it's been much more straightforward than I'd feared.] -- Colin Watson [cjwat...@debian.org]
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: > > > [Ian Jackson:] > > > > You should use dgit for the benefit of users. See my other mail which > > > > answers why Vcs-Git and debcheckout is not enough. > > > > > > could you be so kind and provide a pointer, this thread is rather long > > > already? (Maybe this is also worth an FAQ entry somewhere..) > > I meant this message: > https://lists.debian.org/debian-devel/2019/05/msg00065.html thanks for the pointer, but I don't see the string debcheckout in that message and vcs-git only once, where you write: ---begin quote--- >From these we can conclude: * 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. And if it's not set, it's either because the package is not in git or because d/control is lacking information, aka the package is buggy. So, IOW, I can see problems with individual packages here but not with the general workflow/tool of using vcs-git: and debcheckout. (or what am I missing?) -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
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"):
> could you be so kind and provide a pointer, this thread is rather long
> already? (Maybe this is also worth an FAQ entry somewhere..)
Jonathan Carter writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> I'd like to second that request, I mean to go through this thread again
> when I have some free moments, but a FAQ would help a lot to assimilate
> all this information.
A FAQ is a really good idea. Thank you for the suggestion.
In the meantime,
> > [Ian Jackson:]
> > > You should use dgit for the benefit of users. See my other mail which
> > > answers why Vcs-Git and debcheckout is not enough.
> >
> > could you be so kind and provide a pointer, this thread is rather long
> > already? (Maybe this is also worth an FAQ entry somewhere..)
I meant this message:
https://lists.debian.org/debian-devel/2019/05/msg00065.html
> (I'm in a similar boat to Holger with my experience to gbp, I tried
> going through the documentation on the wiki a few times and just got
> frustrated. I just use packaging and Vcs-fields and tags and nothing
> fancier than that, which works for the few dozen packages I have and I
> think the workflow is trivial enough so that downstream consumers
> wouldn't have any problem whatsoever figuring out how to make use of it,
> but I suppose as that list grows it will become important to have
> worflows that scale up a bit more.)
I confess I always find these kind of comments (which I hope you won't
mind me parodying as "I don't use anything") a bit confusing because
they don't explain how you perform the key task that tools like gbp pq
are intended to help with.
I think what is going on here is this: to you, what you do for that is
so completely obvious it doesn't occur to you that I don't know what
it is. There is such a gulf here between different people's workflows
that we are having trouble communicating.
If you are maintaining a package in "3.0 (quilt)", you are maintaining
a series of patches to the upstream part of the package. The question
is: what tool(s) do you use to change what changes a patch makes to
the upstream source, edit a patch's accompanying message (if you give
them messages), add a new patch, drop a patch, rebase the patches onto
a new upstream version, and so on.
The answer clearly isn't "nothing" since you're not fiddling with the
individual bits in your computer's RAM by your electrotelekinetic
superpowers :-). At least if you are then awesome but maybe you are
beyond need for version control software.
I guess the answer probably isn't even "I edit the diffs in the
patches, in my text editor". At least I hope not since editing diffs
in a text editor is still horrific even with a really good text
editor. I think that probably many people who say "I don't use
anything fancy" are using quilt, or maybe raw diff and patch ? Maybe
you are editing debian/series with your text editor and occasionally
using rm and mv on patch files ? Or git-mv and git-rm ?
I realise the above might sound facetious. That's not my intent.
Ian.
--
Ian JacksonThese 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.
