Re: golang-* not on Salsa
Hi Simon,
Am Tue, Sep 09, 2025 at 10:02:20AM +0200 schrieb Simon Josefsson:
> > 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.
Hmmm, thinking twice about this I now understand that you mean kind of a
dependency tree which would be actually hard to approach with SQL. I
was thinking more the simple approach: If package golang-X is not
mentioned in any Depends or Build_Depends we might not need it any more.
Popcon is as well in UDD so we can adjust this removal warning with some
threshold popcon value.
However, sometimes its easier (by using routine-update for instance) to
simply update the package and decide more generally whether a package is
needed or not. The fact, that it was not uploaded since the Alioth
migration does not necessarily mean that its a candidate for removal nor
is the other way around that a package was uploaded with proper Vcs
fields set a guarantee that it makes sense to keep it.
> >
> > Definitely. I admit last weekend I started with these packages:
>
> I noticed :) Thank you!
You are welcome. I'll keep these as some low hanging fruits when being
in need of such.
> > 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.
I once invented routine-update for R packages where it was extremely
convenient. It works best when a package is featuring a valid watch
file (and several golang packages I've seen are lacking one which I
fixed for the package I uploaded).
> > 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'm not sure. I was watching a couple of videos which I missed when
being at site since I prefered the not-recorded events.
> > 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.
So I will not automatize this change for the moment but I think I'll
keep on doing this if nobody might raise strong reasons not to do this
here.
> >> 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
Kind regards
Andreas.
--
https://fam-tille.de
Reply to: