[MacPorts] #63979: qca and subports: revisions have not been restored correctly

MacPorts noreply at macports.org
Sat Nov 20 10:24:36 UTC 2021


#63979: qca and subports: revisions have not been restored correctly
-------------------------+----------------------
  Reporter:  ryandesign  |      Owner:  RJVB
      Type:  defect      |     Status:  assigned
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:
      Port:  qca         |
-------------------------+----------------------

Comment (by RJVB):

 Replying to [comment:9 ryandesign]:

 > That's nice. But if a user still had e.g. the old qca @2.2.1_0 from 2019
 installed, MacPorts would not have upgraded them to your new qca @2.2.1_0.

 Full disclosure: that's what I had (still have, probably, in deactivated
 state). I don't often bother to reinstall my own ports if it's just for a
 revbump because of some dependency that I also didn't bother to upgrade,
 esp. not if I have a custom copy in my own ports tree.

 To be honest, I'd like to see proof that this is an actual issue, and not
 yet another clash of principles. As far as I've seen (= often enough),
 increasing the epoch simply causes a forced upgrade allowing for a
 complete change of the versioning scheme (i.e. to one that cannot be
 compared to the previous version sensibly). And that should still be the
 case unless this was changed in a newer "base" version that I haven't yet
 updated to.

 > You are the maintainer of the port and are responsible for maintaining
 it correctly. You are the one who knows whether you've changed anything in
 the port that warrants a revision increase as compared to the port's
 previous iteration. You should set the revisions as needed, per my
 original report.

 Well then we're all set - nothing warrants a revision increase, and in my
 opinion the downgrade warranted a reset of the revisions (again, in my
 opinion, because major version change and a change of epoch).

 It's accepted practice that others revbump ports they don't maintain when
 there's a reason; this seems to be the case. You know I don't have commit
 permissions to do this myself, and I'm not going to do it through a
 dedicated PR.

 FWIW: if memory still serves me well, I certainly didn't ask to be the
 sole maintainer of this port, there must at least have been a co-
 maintainer (I think I was asked to maintain the Qt5 subports). I also
 don't know why the port doesn't have `openmaintainer` status; it should.

-- 
Ticket URL: <https://trac.macports.org/ticket/63979#comment:10>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list