Easy access to external repositories.

David Strubbe dstrubbe at macports.org
Mon Jun 1 09:15:00 PDT 2015


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?

David

On Mon, Jun 1, 2015 at 11:44 AM, René J.V. <rjvbertin at gmail.com> wrote:

> On Monday June 01 2015 15:56:32 Thibaut Paumard wrote:
>
> > One usual and easy solution to this problem is to use lexicographic
> > order and let the files start with a number: e.g.
> >   10_macports.conf
> > is the default, most third party repositories should have a name
>
> Which also means that you have to rename all files if you want to change
> order.
>
> 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 .
> 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.
>
> > I tried to write the Portfile so that when one tries to uninstall it, it
> > will undo whatever was done during installation.
>
> 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).
>
> 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.
>
> 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 :)
>
> > I was just thinking that since this [per-port priorities] hasn't been
> done before, it is going to
> > have a higher risk and likely take longer to "bring to market".
>
> 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.
> 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:
>
> if port has priority setting
>   set prefdir to port preferred repository
>   if prefdir = "default" set prefdir to default repository # redundant but
> what the heck
>   set portdir to port preferred repository if it exists
> set portdir to default repository if unset
>
> R.
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150601/3b8cd7a0/attachment.html>


More information about the macports-dev mailing list