On 3/1/20 1:46 AM, Tong Sun wrote:
On Fri, Feb 28, 2020 at 5:35 PM Dmitry Smirnov <onlyjob@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).