On Oct 3, 2020, at 06:05, Lothar Haeger wrote:
>> It's because, besides being an unimaginably large amount of work in
>> rearranging our code to do it, I have absolutely no idea how it would be
>> accomplished without providing the user with unlimited opportunities to
>> create broken combinations of port versions, which would generate an
>> unlimited number of bug reports that we would then need to respond to, and
>> my goal in MacPorts is to reduce, not increase, the likelihood that users
>> would find something broken or need to contact us to help troubleshoot it.
>>
>> If you have an idea for how it could be done without such problems arising,
>> please open a new topic and describe it and we can talk through a few
>> scenarios and see if it works.
>
> I do have some ideas (not mine, just looking at how it works elsewhere), but
> not the time to drive something of this size, to be honest. Basically, we'd
> need to
> - keep and distribute all Portfile versions (including patches and files),
> not just the lastest
> - add required versions to dependencies (can be version ranges e.g. >=1.2.3
> or 2.* or 1.2.3-4.5.6)
> - add support to install individual ports in into separate folders or give
> them individual names on install time (much like with the perl versions), so
> multiple versions of a port can be installed in parallel.
> - add command line parameters to the port command so users can optionally
> specify a version to install (defaults to latest) and a pre/post fix to
> install location or file names or both (depends on how stuff gets
> implemented, of course)
> - add support for dependency resolution including version information. So if
> two ports have different, non overlapping version requirements for a
> dependency, that dependency gets installed twice. Making sure each port then
> actually uses its matching version is probably one of the trickier parts here.
>
> Implementing all this would be a major project and I totally understand that
> it's nothing to jump at without considering all the consequences and outside
> factors.
It would be a major project if it were clear how it could possibly work and it
were just a matter of doing it. But so far I have no idea how it could work.
Just looking at your idea to distribute all portfile versions, let's start with
the fact that portfile syntax has evolved over time. A portfile from ten years
ago can't even necessarily be parsed by today's MacPorts ("livecheck.type" used
to be called "livecheck.check"; there used to be "cd" and "suffix" procedures
that ports used to use) or it may behave differently than it did then
("platform" blocks used to behave like variants and their code was evaluated at
the end of the portfile rather than where it's declared; the way that the
arguments of startupitems and configure.env/build.env/etc need to be quoted was
changed).
Libraries change over time. Sometimes when a library changes it means that the
other ports that use that library need to be patched. Obviously those patches
were not in the old versions of the portfile that predate the new library, and
patches for the current version of the software couldn't necessarily be used on
old versions without being rewritten.
Compilers and operating systems evolve. Xcode 12, for example, prohibits
implicitly declared functions. We're adding patches to ports as fast as we can
to fix these problems, but old versions of the portfile would not have those
patches.
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.
>> I'm speaking of the user being able to specify an arbitrary version.
>
> So do I.
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.
>> I consider it a feature, not a bug, that we offer multiple ports for
>> different versions of perl, php, python, ruby, gcc, clang. It enables the
>> user to install multiple versions of those languages that can all be active
>> and available at the same time. If the user has one script that works with
>> python 3.8 and another that requires python 3.6, no problem. If they have
>> one web site that works with php 7.4 and another that needs php 7.2, no
>> problem. If we only had a single python or php port that only let the user
>> choose a single version to install at a time, that would not be possible.
>
> I totally agree that this is a great feature. Only it's limited to a few
> versions of a few ports due to the way it's being implemented. Supporting
> this for more ports and version does not scale well, twice as many
> ports/versions cause twice as much work. With thousands of ports in the tree
> the current approach will always be limited to a handful of ports.
Exactly: it's a lot of work to implement it correctly, which is why it's only
done for a few ports where it's really useful.
> If this was implemented as general features to a) install any port version
> and b) install several instances of any port, we'd get the same for each and
> every port/version out of the box.
I have no idea how the manual labor that we currently expend on implementing
this feature selectively could be automated or generalized to all ports.
