> 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
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
