[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS/package review




On 11 June 2021 4:00:15 am IST, Peymaneh Nejad <p.nejad@posteo.de> wrote:
>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.
 
Hmmm....
You could've done (<< 0.3.9) not the best solution, but better than an exactly equals.
Because say a changelog revision (and not a new version) happens anytime soon, that (=) thingy will break, and hence it's a bit too fragile.

>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.

Sure, but think of it this way: even if say a 0.3.9 upload is done, and it breaks our package, we can just "backport" the fix and upload, right?
That's have fixed it.

The problem is using stuff like exactly equal or << is bound to break the package some day or the other when the dependency is updated, and we have to fix it :-)
That is one of the reasons maintaining packages is hard and absolute fun at the same time :-)


>> * 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

Aye, that looks great! Many thanks :-)

>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

Coolio!

Nilesh

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Reply to: