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

Re: Procedural questions



On Sat, Apr 13, 2019 at 4:54 AM Abel Luck <abel@guardianproject.info> wrote:
>
> Hi folks,
>
> There is a set of go tools that we use for sysadmin/devops work, and
> getting them into debian proper would be a huge boon in terms of
> ease-of-install and use. These tools are widely used, so debian
> packaging would presumably benefit the wider community.
>
> Intrepidly I set out to package these tools myself, but I've found
> myself in a deep dark dependency pit and am in need of advice.
>
> There seems to be 3 cases when it comes to dependencies:
>
> 1. A dependency is not yet packaged
> 2. A dependency is packaged, but the version in debian is older than the
> version required
> 3. A dependency is packaged, but the version in debian is newer than the
> version required
>
> Case #1 is simply a matter of recursion, no questions there.
>
> My questions are about #2 and #3.
>
> This seems to raise a philosophical question of sorts. Since it is
> evidently common in the go community to pin versions of certain
> dependencies, it is the case that you can run multiple tools
> side-by-side that are using different versions of one dep.
>
> What's the proper way to handle these cases?
>
>
> For context, two of the problematic packages that exhibit cases 2 and 3 are:
>
> dh-make-golang github.com/devopsmakers/xterrafile
> dh-make-golang -allow_unknown_hoster go.mozilla.org/sops

Hi Abel,

For cases 2 specifically, the following might be helpful (e.g. using ratt):

---------- Forwarded message ---------
From: Shengjing Zhu <zhsj@debian.org>
Date: Sun, Mar 10, 2019 at 5:00 AM
Subject: Re: Updating golang-github-ghodss-yaml

On Sun, Mar 10, 2019 at 1:15 PM Tong Sun wrote:

> I'm thinking to update golang-github-ghodss-yaml as it is about two years old now and some useful functionalities have been added in. So, the questions are:
>
> - would there be any objections?
> - for two years the upstream author didn't publish any new version. Would the procedure be trying to nudge him for a new version first before going to the latest git version? How long should I normally wait, if upstream author is not responsive, before going to the latest git version?
>

I think you can update when it's needed. For example, your package
needs new version, or bugs in old version.

And just pay attention to coordinate with the reverse dependencies,
you can use ratt[1] to check if the new version causes regressions.

[1] https://packages.debian.org/unstable/ratt


Reply to: