<div dir="ltr">A general question: what is the purpose of adding a repo for the ESO software, as opposed to just committing the individual Portfiles that exist in that repo to the standard MacPorts repo?<div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 1, 2015 at 11:44 AM, René J.V. <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Monday June 01 2015 15:56:32 Thibaut Paumard wrote:<br>
<br>
> One usual and easy solution to this problem is to use lexicographic<br>
> order and let the files start with a number: e.g.<br>
> 10_macports.conf<br>
> is the default, most third party repositories should have a name<br>
<br>
</span>Which also means that you have to rename all files if you want to change order.<br>
<br>
It would be easier to use a separate file in sources.conf.d, say sources.conf.d/order which lists the files in the desired order of priority, possibly with tags like nosync .<br>
Of course then you're back to rewriting a file like with sources.conf itself, but one with a simpler format, and less crucial. For instance, base could reject the file and use only sources.conf if there's some form of corruption.<br>
<span class=""><br>
> I tried to write the Portfile so that when one tries to uninstall it, it<br>
> will undo whatever was done during installation.<br>
<br>
</span>So is there 1 Portfile per external repository? Did you handle deactivation or did you simply make it impossible (which would probably be the best thing to do but I don't know if it can be done).<br>
<br>
I still think that whatever can be done with a Portfile in this domain can also (and better) be done with a dedicated script, a la add-port-repository.<br>
<br>
All this got me wandering to wondering about hacking a version of APT on top of the port command ... no, I don't think I just admitted that :)<br>
<br>
> I was just thinking that since this [per-port priorities] hasn't been done before, it is going to<br>
<span class="">> have a higher risk and likely take longer to "bring to market".<br>
<br>
</span>I doubt that. AFAIK MacPorts uses indices ("portindex" files) internally, and I find it difficult to believe that it'd be hard to get this right without long periods of testing.<br>
Anyway I think that those port priorities would be optional, fall back to the default priority if they don't compute, and at least in a 1st implementation only concern from what repository a given port is installed. That's not particularly hard to implement:<br>
<br>
if port has priority setting<br>
set prefdir to port preferred repository<br>
if prefdir = "default" set prefdir to default repository # redundant but what the heck<br>
set portdir to port preferred repository if it exists<br>
set portdir to default repository if unset<br>
<div class="HOEnZb"><div class="h5"><br>
R.<br>
_______________________________________________<br>
macports-dev mailing list<br>
<a href="mailto:macports-dev@lists.macosforge.org">macports-dev@lists.macosforge.org</a><br>
<a href="https://lists.macosforge.org/mailman/listinfo/macports-dev" target="_blank">https://lists.macosforge.org/mailman/listinfo/macports-dev</a><br>
</div></div></blockquote></div><br></div>