On Mon, Mar 2, 2020 at 12:06 PM Arnaud Rebillout <[email protected]> wrote: [...] > 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). >
BTW, I'd like to share my concerns about some particular workflows. Before buster release, I tried to NMU docker.io to make it migrate to buster in time. It's really hard for me to figure out how to build docker.io from the git tree. I ended up building it without git and gbp. I just run ``` apt source docker.io cd docker.io-* sbuild ``` It's fine, and it's common to NMU other packages in Debian. Because when NMU, we usually don't touch the VCS, and only send debdiff to BTS. But if it's team upload, I hope we can work out a common practice to update packages both in archive and VCS. -- Shengjing Zhu
