add a concept of 'distributions' for ports that work on specific older architectures

[kenneth.f.cunningham@…]

A number of macports users (like me) like to continue to make use of machines that are tied to older architectures. PPC Tiger, PPC Leopard, and X86 Snow Leopard seem to be the most used. I have a number of machines that are locked into those states, all doing useful things.

There are many ports that install correctly on these machines, but as ports are updated, there is an increasing likelihood that these systems will be left behind. There is not an easy way at present to find a collection of ports of various versions that last worked well on PPC Tiger, for example -- but there is such a collection, and it contains a lot of useful software (Apache2, MySQL, and many more). Yet every time we port selfupdate, the entire collection is in jeopardy.

It would be useful to virtually 'freeze' macports at a certain point in time, with tools and ports that work well for a certain architecture. As the ports are upgraded / updated beyond that point, the PPC Tiger machine (for example) could continue to access the state of macports that last worked well. Ports could be updated / added to that 'distribution' as they are found to be workable with it.

[ryandesign (Ryan Carsten Schmidt)]

We barely have the manpower to correctly maintain our existing single collection of ports; we certainly don't have the manpower to maintain separate distributions for different versions of Mac OS X (or, as has been requested elsewhere, stable and unstable distributions). What would happen is that developers would update the latest and greatest port collection, while the other port collections would not receive timely updates. The consequence would be that users using those other port collections would receive unnecessarily outdated or buggy software. Instead, I would like to keep our single distribution, and update ports and fix bugs as they're found.

We do provide frozen port collections every time we release a new major version of MacPorts. They're in the ​download directory and have names ending with "-archive". However, there are no guarantees with these frozen port collections that they work on any particular version of Mac OS X, which is the same situation as our live up to date ports collection.

[kenneth.f.cunningham@…]

Thanks Ryan. Based on how many times I see your email address on these pages, I can appreciate your comments about manpower. Wish I could help out more. Perhaps I can learn a bit and be of use. For now -- how would you suggest we best handle the situation that recently arose where an older version of a port, with no apparent significant bugs, worked fine on say Snow Leopard, but a new version (with enhancements) drops Snow Leopard support?

[raimue (Rainer Müller)]

There are no guarantees that ports work at all as all users are on the live version. Port updates are distributed over selfupdate almost immediately after they were committed to the repository. So even on the latest version of OS X, ports may break sometimes.

On what you could do to improve the situation for Snow Leopard, you could provide an ​overlay of the ports tree that pins ports to the last known good version (as an alternative, they could be "pinned" in the Portfile in a platform block). That should only be done if newer versions cannot be fixed in some way through patches. However, as soon as a port no longer works on Snow Leopard, dependents may also break as soon as they require new features. I am not sure there are enough users interested in contributing to these legacy systems at all.

Do you have any examples where ports could not be fixed for Snow Leopard? Often enough it requires someone to debug the issue and provide a patch. Personally, I won't work or care for issues for anything older than two releases of OS X (at the moment, that would be 10.9 Mavericks), but will happily accept any patches for these systems.

[kenneth.f.cunningham@…]

Thanks, raimue. I believe I see how what you suggest can make this work now.

I have an example (perhaps a silly example, but illustrative) for Tiger. The qt4-mac current revision does not work on Tiger (and it never will - the underpinnings moved on to 10.5+ as of the 4.8.x version). But qt4-mac 4.7.4_1 works just fine, and enables certain software to work. That corresponds to r87272 in the qt4-mac portfile history, which appears to be the last revision of qt4-mac that will ever work on Tiger, and which I just installed on one of my Tiger machines without issue. So that version will go into a local port repository for Tiger, and hopefully will stop any upgrade requests for that port. And so on for whatever other similar end-of-the-road ports we / I come across for Tiger.

And likewise for Snow Leopard and Leopard, I can forsee.

And maybe someday I can make this local repository available for someone else to install on their machine, so they will get working ports from the get go on these older systems.

Thanks for the suggestion and info. Ken

[kenneth.f.cunningham@…]

Ok, success. I can confirm this works just exactly as you would expect. The older port revision, in the local portfile repository, supersedes the newer revision in the up-to-date repository. The older qt4-mac port is not flagged for updating after a selfupdate, and appears pinned at that revision, as hoped.

The old source file locations are not always correct, so there's one hiccup to ponder. Just had to download it manually. Will probably have to store those somewhere. And there may be some ports that have no older revision that works on - say - Tiger, so they should just be made to disappear somehow (or at least flag as not installable). I can see how that might be done.

So this somewhat odd and perhaps not-that-useful-to-anyone-but-me project can be done without any significant macports changes.

[kenneth.f.cunningham@…]

I was thinking, without any changes in the current port base, even something like this in the portfile (in this example, the qt4-mac portfile) might go a long way towards alleviating wasted time and frustration...in a perfect world, this error would somehow lead to the appropriate Portfile revision being delivered into a personal repository on that machine, but as you point out, that is another matter entirely.

pre-fetch {
	if {${os.platform} eq "darwin" && ${os.major} <= 8} {
		ui_error "Current versions of qt4-mac are not compatible with MacOSX Tiger or earlier."
		ui_error "Please use revision 87272 for MacOSX Tiger."
		ui_error "For instructions on how to do that, see <https://trac.macports.org/wiki/howto/InstallingOlderPort>."
		error Incompatible_Version_for_OS
	}
}

[kencu (Ken)]

this distributions idea will never be possible.

Marking ports as building or not building on various systems has been done port-by-port and now was recently added to base.