Re: RFS/package review
Am 10.06.21 um 22:41 schrieb Nilesh Patra:
On 6/8/21 3:20 PM, Peymaneh Nejad wrote:
second is golang-github-masterminds-sprig:
https://salsa.debian.org/go-team/packages/golang-github-masterminds-sprig
Uploaded this one (to NEW) too. Few changes:
* You had an exactly equal (=) B-D on golang-github-imdario-mergo-dev - I don't see much of a reason to do that either
that makes it fragile, should be (>=)
That was on purpose, I forgot leave a comment regarding that decision. Reason is
a bug/API breakage introduced with github.com/imdario/mergo 0.3.9:
https://salsa.debian.org/go-team/packages/golang-github-masterminds-sprig#important-notes
As I understand the policy manual, a statement like (=0.3.8 || >= 0.3.10) is not
supported and because I could not foresee if the update of the debian package
would jump to 0.3.9 or the newest, I thought this would be the best solution.
Now that I am looking into the go.mod file again, I see that
golang-github-masterminds-sprig should rather build on
golang-github-imdario-mergo-dev 0.3.11 (which is not in unstable yet), as the
bug was reverted in mergo 0.3.10
I must have overlooked that, I will look into doing a revision.
* Relax B-D on version Build-Deps with a "~" That makes it help go to backports, and eases installation+building from experimental too
* Since it depends on a new version of masterminds-semver-dev, added an (>= 3.1.1-1~)
Please take a look at my commits. Let me know if you want more explanation
Also two pointers (in general):
* Please send RFS mails package wise. As in send separate mails with different subjects - '[RFS] <package-name>'
otherwise, this thread has already got pretty log, we discussed about a few packages already with a generic subject 'Package review'
Understood :)
* Just a suggestion: Since caddy has a long dependency list with several version updates,
Can I ask you to make a salsa wiki and/or debian wiki (whatever and however you prefer) to track this?
wiki should mention what versions is needed, what is already packaged, which package is in experimental for instance.
I don't have very good examples to give here, but you can take a look at how it's done here[1] and here[2]
This will serve several purposes:
a) Help us push things to unstable after we have bullseye, otherwise tracking everything is hard
b) Know which packages are in new, and monitor them
c) Know which packages are lagging in versions needed, and adjust them
d) Give an overall idea of progress -- things that are needed and other stuff is missing.
Tracking via e-mails is fine too, but as you might have realized, multiple mails start making it a bit messy, and hard to keep track of everything
That makes sense. I have set up an issue tracker mainly for myself:
https://salsa.debian.org/peymaneh/gsoc/-/boards/2932
Right now it mainly serves for planning my schedule but I will complement it so
it can serve as a general dependency tracker as you propose
Reply to: