Supporting installing arbitrary port versions

Ryan Schmidt ryandesign at macports.org
Sun Oct 4 05:36:13 UTC 2020


On Oct 3, 2020, at 23:40, Jason Liu wrote:

>> Just looking at your idea to distribute all portfile versions, let's start with the fact that portfile syntax has evolved over time.
> 
> This is where portfile syntax itself can, and probably should, be versioned. Maybe by incrementing PortSystem? i.e. PortSystem 1.3, 1.4, 2.0, etc. Similar to how the HTML standard specification's version number has changed over time, from HTML 2 all the way to the current HTML 5.

Yes, we could do that starting now, but since we haven't up to now, the problem exists. The portsystem version concept was part of the original MacPorts design, predating the involvement of everyone here, so we would have to figure out how it works, whether it was ever fully implemented, what the implications would be of increasing the version, etc.


>> If MacPorts allowed the user to pick an arbitrary old Portfile to install, it is extremely likely that the user would experience an error.
>>  
>> If you are suggesting that we should not only distribute all old portfiles but also keep them all updated as needed, that would be a ludicrous amount of work that nobody would be willing to do.
> 
> This is where being able to restrict dependencies to specific version ranges would be incredibly useful. If you could say that a portfile's dependency requires a version >= 1.3.0 && <= 1.5.2, then you would not need to update that old portfile once the dependency's portfile gets updated to a version beyond 1.5.2.

I don't think I understand. Could you make the example more specific by using (real or made up) port names?


>> Well you spoke of keeping all Portfile versions. So perhaps you're suggesting the user should be able to select from any past version of the port. That's slightly more reasonable than allowing the user to request any version of the software regardless of whether that version has ever been in the portfile, but still completely impossible and unsupportable as far as I can see so far.
> 
> Other PMSes like APT and YUM do exactly that. They keep all versions of their package's spec files. How they do this is that their package repositories have a different architecture than how MacPorts is currently laid out.
> 
> [Note: What follows below is a fairly lengthy description of how another package management system works. If you have no interest in such things, here is probably a good place to stop reading.]

Thanks, I am interested to the extent that if someone else has a solution that would work for us, that would be good to know.

You've described how they keep their current and historical "Portfiles" on a server and download them on demand rather than keeping the current ones all pre-downloaded on the user's computer. But you haven't addressed how you could build historical "Portfiles" on a newer OS or compiler version when they would not have been written to account for the new restrictions imposed by that newer OS or compiler version, and we go back to my supposition that a portfile maintainer would be asked to keep updating and patching ever old versions of their portfile.



More information about the macports-dev mailing list