Hi Ramūnas,
On Mon, 30 Oct 2023 16:02:38 +0200, Ramūnas Keliuotis
<ramunas.keliuotis@nordsec.com> wrote:
[…]
> On Sat, Oct 28, 2023 at 9:06 PM Stephen Kitt <skitt@debian.org> wrote:
> > On Wed, 25 Oct 2023 09:01:10 +0300, Ramūnas Keliuotis
> > <ramunas.keliuotis@nordsec.com> wrote:
[…]
> > > I was following the `dh-make-golang` example. I am not the owner of
> > > this package, but it is a dependency for my primary golang program
> > > NordVPN.
> > > Was strange to me that it is an ITP request - it is for the owner or
> > > maintainer. Probably this should be an RFP.
> >
> > If you intend to maintain the package in Debian, then an ITP is
> > appropriate. If you’re asking for someone else to maintain the package in
> > Debian, then an RFP is appropriate.
>
> Could you give more details on what would mean `maintain the package`?
> If I would prepare it for upload, then ask to upload it, polish some
> bits if needed, but not any fixing in code as this is a 3rd party
> package, not my own.
> I guess it would be quicker if I did it by myself. Otherwise I would
> need to wait undetermined time for someone to do it as it is not an
> interesting package to anyone else.
> Will I be obliged to prepare new version upgrades or any other effort
> will be needed? Just trying to evaluate the effort needed if I would
> take this role.
To get an idea of what maintainership entails, see
https://www.debian.org/doc/manuals/developers-reference/developer-duties.en.html#package-maintainer-s-duties
— in short, maintaining a package means getting it into shape for the next
release of Debian, responding to bug reports, and liaising between the
upstream developer and Debian and its users.
It is quite common for Debian maintainers to end up maintaining niche library
packages which are required for the packages they mainly care about. When
that happens, the maintainership can be limited to the needs of the main
package, but it often happens that others then start using the library
package and the maintainership scope expands. So you would typically not
*have* to prepare version upgrades unless your main package needs them, but
that may well change at some point — and in any case, even if your main
package doesn’t require an upgrade, it would be best if you did at least keep
track of new upstream releases and evaluate whether it’s important to package
them or not (e.g. if they fix important bugs).
Go packages are typically team-maintained so the burden doesn’t have to be as
heavy as for packages maintained by a single person.
You would *not* be expected to fix upstream bugs or add upstream features;
Debian maintainers do often end up providing upstream bug fixes but that’s
not a requirement. A maintainer’s role can stop at forwarding relevant bugs
upstream and interacting with upstream as appropriate to help resolve it (or
enlist the original bug reporter’s help to keep things moving). However if a
bug is important enough in Debian, the package can be withheld from a
release, and in some cases the only way to avoid that is to fix the bug
rather than wait for upstream to do so.
> > > `dh-make-golang` program example/tutorial is probably oriented for go
> > > package owners or maintainers.
> > > Here is that tutorial:
> > > https://people.debian.org/~stapelberg/2015/07/27/dh-make-golang.html
> > > I found reference to that tutorial in `go-team` packaging page:
> > > https://go-team.pages.debian.net/packaging.html
> > >
> > > Please, advise me how to proceed with packaging third party golang
> > > packages which are my golang program's dependencies and are not yet
> > > available in Debian SID.
> > >
> > > Some examples of my dependencies which are not in SID yet:
> > > github.com/esiqveland/notify v0.11.2
> > > github.com/godbus/dbus/v5 v5.1.0
> >
> > This one is already packaged: https://tracker.debian.org/pkg/golang-dbus
>
> Right, found it. But only Debian package naming is different from the
> established naming system.
Yes, it’s not obvious.
> > > github.com/Microsoft/go-winio v0.6.0 // indirect
> >
> > As others have mentioned on your ITP for that, it might not be necessary
> > in Debian — you need to determine which dependencies are really needed
> > (don’t look at go.mod or go mod graph, build the binary you’re interested
> > in and run "go version -m" on it).
>
> Thank you! Indeed, have to clean dependencies first.
Note that my comment above is over-simplistic — you obviously need binary
dependencies ("go version -m") but there can be other dependencies required
to build the package (e.g. test dependencies if you run the test suite, or
build tools which aren’t packaged yet).
Regards,
Stephen
Attachment:
pgpa2Dw9vlAOL.pgp
Description: OpenPGP digital signature