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

Re: Basics of packaging with the new workflow



Hi Dmitry,

I started replying but my mind wandered and made it too long, so the
TL;DR version is:
add the "-dep14=false" flag to keep using "master" as debian-branch.
"dh-make-golang make -help" for details.

On Sun, Feb 23, 2020 at 7:47 PM Dmitry Smirnov <onlyjob@debian.org> wrote:
>
> On Sunday, 23 February 2020 5:03:23 AM AEDT Shengjing Zhu wrote:
> > So when you create a new package with dh-make-golang, it creates two
> > branches for you,
> > + debian/sid
>
> Can we please not make it default? I find it to be highly inconvenient.
>
> IMHO "master" branch fits the purpose much better. Thanks.

The default of "debian/sid" is proposed in DEP-14, see and
https://dep-team.pages.debian.net/deps/dep14/

Over the past couple years, I myself have slowly come to accept that
"debian/sid" as the new default debian-branch for the following
reasons:

 1. "master" may often mean the upstream master branch.
      One needs to take extra steps such as checking for the presence
of debian/* or viewing git log to make sure it is indeed a Debian
branch and not the upstream master.

 2. "debian/sid" explicitly spells "Debian", the "sid" or
unstable/development branch.  No ambiguity.

 3. "debian/sid" naming fits well with branches for backports, e.g.
"debian/buster-backports"

 4. A few developers (Martina, and perhaps Tincho too?  My memory is
vague) started converting some repos from master to debian/sid, and
recently, I have joined that rank, as in I have a bsah script that
automatically converts master to debian/sid and updates the default
branch on Salsa, almost whenever I touch an existing package (usually
in fulfillment of hugo's build dependencies.)

That said, I can totally understand the sentiments attached to "master".
To keep using "master" as debian-branch, simply use the -dep14=false
option, like so:

    dh-make-golang -dep14=false github.com/spf13/cast

(Yes, -dep14 actually defaults to true, haha)

I have some of my own attachments too, e.g. I think pristine-tar
branch can be kept even in the new workflow: pristine-tar may have
issue with XZ-compressed tarball, but it is often fine for
GZIP-compressed tarballs, which is the case for unpacked upstream
release tarballs provided by GitHub, which probably applies to a
majority of the package nowadays.  And that's why the packager may
choose to run dh-make-golang with "-pristine-tar=true" to let
dh-make-golang create the pristine-tar branch as before.

dh-make-golang probably should have the ability to read user's
preference from ~/.config/dh-make-golang.conf or
~/.config/dh-make-golang/dh-make-golang.conf

That said, consistency across packages would be nice too as it allows
us to save time and effort, and allows for more automation.
But yeah, allowing individual's preference is important too.  Hard to
say, hoho!  I will leave it up to other team members to reach a
consensus.

By the way, thank you very much for fixing problems that I created in
several of Go packages!  Very much appreciated!

Cheers,
Anthony


Reply to: