On Sat, 2021-10-30 at 08:32 +0200, Aloïs Micard wrote: > On 30/10/2021 04:51, Mathias Gibbens wrote: > > Hello, > > > > I would like to join the Go packaging team on salsa. I'm not yet > > a > > DM/DD, but I do have a salsa account; my username is gibmat. > > > > Granted! Welcome on board :)
Thanks! > > > One question I do have for the team: how do you handle re- > > introduction of Go packages that existed in Debian before, but for > > one > > reason or another were then removed from the archive? For example, > > golang-github-juju-schema (RM'ed as it was a leaf dependency for > > another Go package that an individual was working on packaging) or > > golang-github-juju-testing (RM'ed because of dependency on mongodb; > > I > > suspect we'll just drop the mongodb-specific parts of that > > library). > > Both those packages still have git repositories on salsa. > > > > The Debian policy has a section on this topic [1]. > > Basically it depends on the use case, if it's is essential for the > package you're working on, then brushing up and reintroducing the > package > make sense of course. These things happens and packages gets > reintroduced > because someone else has the need. Make sure to check why the package > has > been removed tho, it may give useful pointers. > > On the other hands, if the package is only a test dependencies and > like > used only a few times (this notion is relative) then I would think of > reintroducing it 'too much'. (of course it's my own opinion). In this > case > I would write a patch to remove the usage of the package, and even > submit the > patch upstream maybe? (Why everyone is rewriting their own test > library these > days instead of using what std provides :D) Or the numerous forks on github that have no significant (or any) changes from the original repository, yet one of the forks randomly seems to be the one that everyone uses.... > > I guess you should compare the two options and follow the one that > feels 'best' > (i.e (re)introducing a package is work, take time to maintain, etc... > while sometime > if it's only used a few time, a patch could be helpful). But again > it's mostly my own > opinion! Yeah, I personally try to make minimal changes when working on packaging, and try to upstream as much as possible so I don't have to maintain the diff. I'm lazy, but in a good way. :D > > > > I will be following the ITP/RFS pattern for packages that I work > > on, > > although for the first couple ones I'll likely ask this group for > > some > > focused critique to ensure I'm creating good Go packages for > > Debian. > > > > Sure thing! Have fun with the process. This weekend I'm hoping to get a couple simple packages ready for review, and I'll ping the group when that happens. > > > Thanks, > > Mathias > > > > Cheers, > > [1]: > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#reintroducing-packages >
signature.asc
Description: This is a digitally signed message part
