Andreas Tille <andreas@an3as.eu> writes: >> Could you run some dak spell on all golang-*-dev packages and see >> which ones have no consumers, and we could then perhaps just remove >> them from Debian as obsolete? > > This would rather find package dependencies, right? I have no idea > about DAK but it could be queried via (build_)depends in UDD. Do you have a UDD spell? I started to explore that after Otto's e-mail, however I quickly realized that recursive figuring out the proper reverse build dependencies is non-trivial. I'm not even sure this is possible to express in SQL, but a reasonable approximation should be good enough. I think a dak spell should work but has to be invoked multiple times and it is very slow. >> And for the remaining ones, we should probably not do an upload to >> Debian with only one line in debian/control changed, but perhaps run >> lintian-brush, > > Definitely. I admit last weekend I started with these packages: I noticed :) Thank you! > and to deal with these easily I added this commit to routine-update: I never know about routine-update, looks like something I've been missing and started re-inventing when I wanted to fix these packages. > Given that at DebConf Golang team BoF at DebConf a more extensive Salsa > CI testing was decided (if I understood the video correctly) Oh. Is there a written transcript? > I took the freedom to change the debian/gitlab-ci.yml of > golang-github-vmware-photon-controller-go-sdk[1] to use the default > Salsa CI job. I was wondering whether I should implement this change > into routine-update as well. Before I do so I would like to hear > confirmation of the team (and Salsa CI admins) that this is OK in > general. I did it for this specific package since I'm not an > experienced Go packager at all and passing Salsa CI was ensuring me > that an upload should be fine. I think we've discussed this several times, and never really reached conclusion because it can be implemeneted in many different ways and everyone adds another opinion to the discussion and nobody assume the authority to commit things. I'm +1 to this, but I'm not speaking for the team. >> check CI passes, potentially update to a newer version >> etc and only then upload? > > In other words: Do what routine-update is doing (which includes > lintian-brush, bumping debhelper compat level, Standards-Version > as well as importing latest upstream), right? +1 /Simon
Attachment:
signature.asc
Description: PGP signature