On Fri, Mar 13 2020, Stuart Henderson <s...@spacehopper.org> wrote: > On 2020/03/13 12:25, Jeremie Courreges-Anglas wrote: >> I *think* I've seen an EPOCH change where a bump was needed for >> consumers, but I have no idea which change and why. Anyway make >> repackage works fine in py-msgpack consumers, that's enough for me to >> say that a bump is not needed (of course that needs PLIST_DB). > > This should only be needed if there is a version number in a > dependency port and that has to change. > >> > # requirements/base.txt >> > RUN_DEPENDS = devel/py-futures \ >> > - net/py-msgpack \ >> > + net/py-msgpack<=0.6.2v0 \ >> >> This should be net/py-msgpack>=0.6.2v0 instead, 0.6.2v0 > 1.0.0. >> With this fixed, ok jca@ > > Depends on the purpose of the RUN_DEPENDS line...
>From my PoV it's just about increasing the chances of pushing a working salt package to end users. > if it's to act as a > hint to future porters that py-msgpack can't be updated with this version > of salt, then bket's version makes a lot of sense. Or it could cover both > min and max versions with something like >=0.6.2v0,<1.0.0v0 (warning I have > not tested that :) Documenting the version requirement occurred to me but I failed to mention it. Your proposal seems to work correctly, ok jca@ I guess a comment in py-msgpack/Makefile would be needed too if the port didn't have a maintainer, but I'll just let Bjorn see what works best for him. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
