#17473: RFE: allow Portfile to upgrade dependents -----------------------------------+---------------------------------------- Reporter: mcalhoun@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts base enhancements Component: base | Version: Keywords: | Port: -----------------------------------+---------------------------------------- Changes (by jmr@…): * cc: jmr@… (added) * version: 1.6.0 => Comment: I don't think this will behave correctly when multiple ports are being upgraded. Won't all ports upgraded subsequent to one that trips the poison_version check have their dependents force-rebuilt as well? -- Ticket URL: <http://trac.macports.org/ticket/17473#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS

#17473: RFE: allow Portfile to upgrade dependents -----------------------------------+---------------------------------------- Reporter: mcalhoun@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts base enhancements Component: base | Version: Keywords: | Port: -----------------------------------+---------------------------------------- Comment(by mcalhoun@…): Upon further consideration, I think the inequality should be strict:[[BR]] force upgrade if installed_version < poison_version.[[BR]] That way, revision increases don't force rebuilds. Uploading new macports.tcl.diff. -- Ticket URL: <http://trac.macports.org/ticket/17473#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS

#17473: RFE: allow Portfile to upgrade dependents -----------------------------------+---------------------------------------- Reporter: mcalhoun@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts base enhancements Component: base | Version: Keywords: | Port: -----------------------------------+---------------------------------------- Comment(by mcalhoun@…): Replying to [comment:4 blb@…]:

Is macports.tcl.diff against an old version, it's 230 lines off against trunk? I did use an old version (the current release), but based on what I've looked at so far,[[BR]] nothing new in the trunk is a problem.

So the usage on this would be (using perl5), when it gets version set to 5.10.0 (or whatever at the time it happens), then poison_version would also be set to that, correct? Correct.

And for future 5.10.x updates, it'd be left at the same 5.10.0 as originally set so slower upgraders coming from 5.8.x would still have the right thing happen? Yes.

Being left at 5.10.0 until a (hypothetical) 5.12.0 is released, then updating to 5.12.0. Yes.

Then it becomes like epoch, once added it can never be removed. If the port maintainer wants to accommodate those slow to upgrade, then yes, it would have to remain.[[BR]] Removing it, however, should pose no problem to new installations or upgrades at or beyond the poison_version.

-- Ticket URL: <http://trac.macports.org/ticket/17473#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS

#17473: RFE: allow Portfile to upgrade dependents -----------------------------------+---------------------------------------- Reporter: mcalhoun@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: Keywords: | Port: -----------------------------------+---------------------------------------- Comment(by febeling@…): Another example of a failure due to the same cause: http://mail-archives.apache.org/mod_mbox/couchdb- dev/200812.mbox/%3c49454ADA.5050908@utoronto.ca%3e This is quite a general problem, it seems, even if it does hit apparently not too often in practice. But every time a library rolls over a version number which some port chose to link against this should strike. Wouldn't it be cleaner to rebuild all dependants of a port every time a port upgrades. I see how this might make small changes to common libraries prohibitively expensive. Is there some good general practice for cases like this maybe? FreeBSD and Gentoo should have the same problem, what do they do? -- Ticket URL: <http://trac.macports.org/ticket/17473#comment:9> MacPorts <http://www.macports.org/> Ports system for Mac OS

#17473: RFE: allow Portfile to upgrade dependents -----------------------------------+---------------------------------------- Reporter: mcalhoun@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: Keywords: | Port: -----------------------------------+---------------------------------------- Comment(by febeling@…): Any package manager that relies on the download-and-build pattern has the problem that it can't really tell if they break dynamically linked binaries/libs when they upgrade libraries (because of new path or new lib name). Unless they rebuild all dependents every time, which is way too expensive, that is. Gentoo is one example of an OS with this style of packages. This is how they solve the problem: http://www.gentoo.org/doc/en/gentoolkit.xml#doc_chap4 Basically, there is a tool (revdep-rebuild) which scans through binaries and checks if dynamic linking still works everywhere. If not, you can rebuild only those packages which are marked, so that they link against existing libraries again. -- Ticket URL: <http://trac.macports.org/ticket/17473#comment:11> MacPorts <http://www.macports.org/> Ports system for Mac OS