On 3/1/20 1:46 AM, Tong Sun wrote:
On Fri, Feb 28, 2020 at 5:35 PM Dmitry Smirnov <only...@debian.org> wrote:
In the spirit of diversity statement we can and should appreciate our
differences as it is the very principle that is largely responsible for
Debian success.,,
Agree, I had been thinking that, we might be taking different routes,
which should be allowed, but as long as we arrive to the same place
that should be fine. And that brings me to the following question,
I think it is fair to say that I have more experience than you - that's why I
expect you to acknowledge when I say something about packaging and I'm
telling you that with strict compliance to DEP-14 and GBP repository layout I
would not be able to accomplish as much as I've been doing.
I'm a completely newbie when it comes to Debian or Debian-Go
packaging, so would you elaborate on this a bit Dmitry, so that newbie
like me can understand the difficulties. I.e., if I'm taking the
DEP-14 and GBP repository route, what kind of road blocks I would
meet, e.g., what were the instances you found that it is not
sufficient?
(not Dmitry here)
For the package docker.io (which is a Go program, but *not* maintained
within the go team), we only have the `debian` directory in the master
branch. We don't use the "merge" workflow where upstream code and debian
dir are merged together.
If I'm not mistaken, both the current workflow and the next workflow are
"merge" workflow, so I'm a bit off-topic here, but anyway, let me share
my thoughts.
In my experience, the merge workflow is OK most of the time, ie. for
simple packages. But it can quickly get in the way for more complicated
packaged.
For docker.io, we need to keep some directories from `vendor`. When you
use GBP to update your package to a newer version, GBP automatically
imports things in the upstream branch, in the pristine-tar branch (if
ever it exists), and creates a tag. So it does a bunch of things
automatically, which is nice, except for one thing: you have to *undo*
it all when you realize that you need to keep/remove things in the
vendor directory (by setting the field Files-Excluded in d/copyright).
More specifically, when I was working on major updates of big packages
like docker.io and containerd, most of the packaging work was about
fighting with the dependency tree, and this work was made *more
complicated* by the merged workflow.
So there are good reasons, for some packages, to prefer a particular
workflow, because it just works better.
(and, part of this discussion, I wonder if in such case you're supposed
to take the package out of the go team because you use a custom
workflow, ot if it's accepted to use a specific workflow).
