Le jeu. 28 août 2025 à 21:05, Otto Kekäläinen <[email protected]> a écrit :

> Hi,
>
> ...
> > It goes like this for gh/dsoprea
> > - d2
> >    |- github.com/dsoprea/go-exif
> >       |- github.com/dsoprea/go-logging
> >       |- github.com/dsoprea/go-utility
> >          |- back to go-exif
> >    |- github.com/dsoprea/go-png-image-structure
> >       |- github.com/dsoprea/go-exif
> >          |- <as above>
> >       |- github.com/dsoprea/go-logging
> >       |- github.com/dsoprea/go-utility
> >          |- back to go-exif
> ...
> > Vendoring? I'm all ears.
> ...
>
> In usql I uploaded 5 new Debian packages, but also vendored 5 ones as
> listed at
> https://salsa.debian.org/go-team/packages/usql/-/tree/7785164aca76909d6eebc2162a9271f1c7c2de0d/debian/vendor
> .
> If you look at usql as an example, keep in mind that
> 7785164aca76909d6eebc2162a9271f1c7c2de0d is the commit that was
> uploaded but it is still pending in NEW queue so FTP Masters might
> still object and demand that every single dependency is a separate Go
> package.
>
> The motivation for vendoring in usql was:
> - Tiny dependencies by the same author (Ken Shaw) used almost only by
> himself in his own project (usql) and very unlikely to be useful for
> any other package.
> - Tiny dependencies that are also outdated/unmaintained, and having
> them as self-standing Debian packages could dangerously increase their
> use when in fact we are waiting for usql to finally drop them
> completely and be the last one using them.
> - Tiny tiny dependencies that have no ITP or other indication that
> they are needed elsewhere, and doing a separate package out of a 116
> line Go file (https://github.com/yookoala/realpath/blob/master/realpath.go
> )
> would be overkill.
>
> I haven't investigated how popular these tools of dsoprea are, but it
> might very well be the case that he is the only one using his own
> libraries, and vendoring them all in one could make sense.
>


Also, there is still an ongoing issue about vendoring the debian way,
which is using M.U.T. (multiple upstream tarballs) and adequate
debian/watch.
Currently we are missing a ctype=golang (see man debian-watch).
If we could deliver an abstract algorithm to uscan contributor "yadd", he
would
implement it in perl.

Reply via email to