On 2025-12-03, Simon Josefsson wrote: > Andreas Metzler <ametzler@bebt.de> writes: >> and have also converted the repo to gbp-with-source-layout, since you >> had been using that for gnash. > > I don't think there is any need to do that generally. I suppose the > Debian Scheme Team could develop a team policy with guidance -- but > given the Go Team's difficulty to agree on policy updates, I wonder if > per-team packaging policies is a good idea in the first place. ... > I have to say that I do prefer the idea of bare debian/ repositories, > but I never got that to work fluently in my own workflow, mostly because > of tool issues that expects unpacked source code is stored in git. I strongly prefer upstream-source-included repositories, so you were definitely right about challenging to find policy consistency ... :) To the broader topic, I am not quite sure I ever recovered from the realization that guix cannot (yet?) be reasonably packaged in Debian. The only reason I maintained a few guile packages was to support guix; I have no real love of guile or scheme... so moving over the packages I was maintaining to a team probably makes a lot of sense! Similar story for a for mes ... have not been able to maintain that package itself or it's guile dependencies either... it might be of questionable use at the moment... I had originally packaged it as part of a cross-distro bootstrapping experiment, but there was always a tension with packagability Debian... I have also had the impression that basically any time any dependency of a guile package changes, it should probably be binNMUed to regenerate the .go files ... especially when it there is an involved C binding ... which I have sometimes done with sourceful uploads, but definitely could not always keep up with. I think *most* of the guile packages are fairly narrow in scope and relatively easy to maintain with well documented licensing and freindly upstreams. live well, vagrant
Attachment:
signature.asc
Description: PGP signature