Re: Preferred git branch structure when upstream moves from tarballs to git
Sam Hartman writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > The latter point is because using dgit push is an ethical
> > imperative, not because the two somehow have some deep
> > technical linkage. IMO almost *any* tutorial being written now
> > about how to do Debian packaging, and which mentions git at
> > all, ought to say to use dgit.
>
> I think this is at the crux of our disagreement.
> I'm going to need to think about this for myself.
OK...
> I think it's safe to say there is not a project consensus that dgit is
> an ethical imperative.
Indeed.
> And yes understanding that you believe that's the case makes it a lot
> easier to understand the rest of your mail.
Good.
> As I said I'll need to think about whether I agree with that. A lot of
> my thinking in this discussion is that I consider dgit a nice to have,
> not a requirement.
I guess I have stated the reasons already, but to recap:
* Users should be able to easily change the software that runs
on their computer.
* "Easily" requires source code 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
apt provides this, if you think tarballs+diffs are enough, but:
* Nowadays people want the source code as the git history.
When upstream and Debian are both using git, then arguably
tarballs+diffs is not really the preferred form for modification.
I.e. the .dsc source package is not really the source code.
>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. Occasionally people propose
alternative technical approaches. So in theory there might be some
other way of achieving the goal. But people have been proposing
technical approaches to this question for a very long time - a decade
at least. Joey Hess and I came up with a design which was actually
implementable, politically practical, deployable and operable, and I
have implemented it, negotiated for it, deployed it, and am now
operating it.
dgit push involves minimal change to maintainer workflows and does not
gore anyone's ox, unlike all most of the (at best vapourware)
proposals before and since.
> If you accept the premis that everyone should be using dgit, I agree
> with you.
> I don't think the gbp documentation has adopted that premis.
Indeed.
> > The only reason dgit needs to get involved in your build
> > process is because of the .gitignore bug. (#908747)
>
> Well, and dgit wants to construct my dsc, which means it wants to
> construct my changes, which... means it wants to call sbuild or
> something else for me.
The only reason dgit wants to construct your dsc is #908747. If you
can avoid #908747 some other way then you can build things however you
like and dgit push will work just fine. [1]
Of course if you are doing source-only uploads, as we should be doing
all the time (we're still shipping maintainers' binaries?!!11eleven)
then you do not need to really "build" anything and `dgit push-source'
suffices. Of course it makes a .dsc but that is an affordance rather
than an inconvenience.
I recognise that your message was in some sense "I will go away and
think" rather than an invitation for me to further engage in advocacy
to you. I hope you don't mind that I've done so anyway. Feel free
not to reply. But I did want to say these things for the benefit of
other readers.
And yes, do please file bugs if you disagree with dgit about things.
I welcome inchoate bug reports, although I don't promise not to reply
with "that doesn't sound right, please send steps to reproduce" :-).
Regards,
Ian.
[1] I would love it if dgit never needed to get involved in building.
There's tons of code in dgit to deal with the quirks of everyone's
favourite build tools. I appreciate that wrapping the build tools in
yet another layer is very undesirable.
All of this is only necessary because of #908747.
Why didn't I try to get #908747 fixed ? Well, it was one of dgit's
original principles that it would not require anyone else's permission
or assistance, at least not for anything remotely controversial.
Without that principle the project would have been totally stalled.
Looking at the history of #908747 you can see that I was right.
The result is that dgit contains many many ugly workarounds. Each of
these workarounds generated a bug report against some other Debian
package. For the most annoying bugs, requiring the worst
workarounds, I don't think any have yet been fixed.
--
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: