[pkg-go] Minutes for the DebConf17 BoF

[Alberto Bertogli]

On Tue, Aug 15, 2017 at 11:02:39PM +0200, Michael Stapelberg wrote:
> 6. I have come to appreciate pristine-tar, as it is the only reliable way
> (that I know of) to prepare uploads for packages which already have their
> orig tarball in Debian. Whenever I come across a package which isn’t using
> pristine-tar, the generated orig tarball will have a different checksum,
> and my upload will be rejected. I’d suggest we codify that pristine-tar is
> a requirement.

As someone very new to packaging things for Debian, here are my 2 cents.

For projects with an upstream git repository, I find packaging using two
branches to be much easier and practical:

 - One branch "upstream" which follows uptream directly.
 - One branch "debian" which is based on "upstream" + patches to the
   debian/ directory.
   To update the package, I just do "git merge upstream" and then make
   the required changes to the debian/ directory.

I find this result in a repo with clean and useful history, as I can
clearly see in the "debian" log the points where the package was brought
up to date, and what changes it required. It also means there's no easy
way to accidentally import a mutated upstream (which can happen if one
just takes snapshots) so it's harder to make mistakes.


No pristine tar branches, those I find terribly confusing and
unnecessary: if everything is in the git repository already, why take
it, turn it into a tar, and shove it back into git again? This requires
additional tooling and maintenance for, what I can see, no real gain.

I noticed that "gbp buildpackage" works just fine without it, and can
build the tar based on the git repo just fine, and in a reproducible
way. The generated tree is 100% reproducible, the points of
non-reproducibility are tar and compression so they're should be rare.

Asking around, it seems that needing the tars is not that common; and
when needed, they can be downloaded from the archives anyway if tar/gz
happened to have changed.


> > dh-make-golang
> > --------------
> >
> > A few times people expressed the desire for dh-make-golang to grow an
> > `--update` option, as most packages are trivial to update, but tedious
> > to do so.

This * 1000 :)

I imagine it would require some assumptions about the way the packages
are handled (branch naming, how upstream is tracked, etc.), which makes
having some degree of consensus about it even more important.


> > API changes in upstream
> > -----------------------
> >
> > We ranted at length about upstreams, and noted that we need a system
> > that provides early warning of API breakages. We discussed using ratt
> > and autopkgtest for that purpose.
> >
> > Aviau pointed out that he usually requests upstreams to make releases
> > and that he is usually successful. Tincho pointed out the problems with
> > meaningless releases and with upstreams releasing once and then
> > forgetting to do it when needed.
> >
> > We discussed the possibility of changing "soname"s by renaming packages
> > when we detect API incompatibilities, but concluded that in general it
> > is too much work and that it makes more sense to try and fix
> > reverse-dependencies by bugging upstream or patching them ourselves.

For C, there were at some point public API checkers that take your code
and will send you a warning if you make breaking changes.

I think such a tool for Go would go a long way with this. You can give
it a "go get"able package, and it would track it and report when the
public API changes, and warn of incompatible changes.


> >   * aviau volunteers to document dh_golang options.

As a newbie, I'd really appreciate this!

I often just rely on asking on IRC or to Tincho directly, because the
way it works seems quite opaque to me.  Luckily most of the things I've
touched so far have been simple enough not to need this.


Thanks!
		Alberto