Easy access to external repositories.

Artur Szostak aszostak at partner.eso.org
Mon Jun 1 05:07:03 PDT 2015


> I'm in favor of simplifying the inclusion of 3rd party repositories. The Portfile
> proposed in the ticket is hack, but since we don't have a standard mechanism to
> do this at the moment, I think we should accept it.

I thought it was a rather clean way to deal with my use case :-)

But sure, what would make it nicer is what I alluded to in a previous email. How about having MacPorts do what YUM does and read additional 3rd party repository configuration files from a directory. Something like ${prefix}/local/etc/macports/sources.conf.d/, and ${prefix}/etc/macports/archive_sites.conf.d/ etc. Then I do not have to modify ${prefix}/local/etc/macports/sources.conf, but rather just add or remove a configuration file from /etc/macports/sources.conf.d/. That would be as clean as it gets I think and how other package managements systems deal with this use case.
Of course the implementer would have to define what the prioritisation order would be for the files under this directory. But I would have the standard MacPorts repository always take precedence over 3rd party ones by default.


> The problem I currently see with an automated approach to add a new repository
> is the order or priority selection. How would you easily decide (in a user
> interface) whether the new repository supersedes the standard one or not?

Should the user interface not simply expose the rules that are already encoded in the core system? Specifically URLs declared first in the configuration files take precedence over URLs declared further down.


> In the long term, this may become easier when (and if) we finish the SAT-solving
> based GSoC project currently running, because that would allow us to have
> multiple versions of the same port provided from different repositories along
> with proper priorities.

Hmm.. well, that would be nice to try solve the generic problem and allow per package priority. But I do not know of any other production package management system that has implemented such a thing. So I would have to say that this is probably years away from stable production. Just look at the MacPorts GUI app, that got started as a GSoC project in 2009 and is still announced as only a beta product (https://trac.macports.org/wiki/MacPortsGUI).
Per repository prioritisation is already implemented in MacPorts, and a SAT solver should be able to easily go from per repository prioritisation to per package prioritisation when it arrives in the future.

Cheers

Artur


More information about the macports-dev mailing list