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

Re: Basics of packaging with the new workflow



On Mon, Mar 2, 2020 at 12:06 PM Arnaud Rebillout
<arnaud.rebillout@collabora.com> 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


Reply to: