Easy access to external repositories.

[Artur Szostak]

>> That is why I propose updating the configuration files through a Portfile, such that the
>> average user just has to run the following commands to get access to a 3rd party repository:
>
> You get me wrong. I'm not sure if it's a good idea to make things too easy to people who
> don't know how to follow instructions to edit a file by hand. Not because it's "too difficult"
> for them to *add* a foreign repo, but rather because of the issues that may come from
> using such a repo, and which will require them to follow instructions more complicated
> than simply adding the repo definition to sources.conf .

Yes, well... I have to find some way to keep my average users happy :-)
Actually, I think it would be kind of useful and a time saver, even for people who know what they are doing when updating the configuration files.


> Does your Portfile undo the edits when you uninstall the port, including after having installed
> a random number of other repos and/or selfupdates (if sources.conf is ever touched during
> a MacPorts upgrade). How does it work with activation/deactivation?

I tried to write the Portfile so that when one tries to uninstall it, it will undo whatever was done during installation. Also the Portfile should only remove what it actually added and nothing else. I have tested this a number of times and it seems to work. I of course welcome independent testing.


> Using a port to add other repos would probably be less of a hack if MacPorts had something
> like a sources.conf.d directory with files each containing a single repository definition.
> However, then you'd lose the simple priority rule and you'd need a separate mechanism to
> specify the order in which repositories are search, rather than the order in which they're
> listed in sources.conf.

Yes, I know. With the sub-directory option, whoever implements it will have to think about a prioritisation scheme. If nothing specific is implemented it will end up being the order as defined by the file-system. An alternative (probably better alternative) would be to have a priority number either encoded in the file or filename.
But I leave it to a core MacPorts developer to think about those details further.


> In any case I think it would be better to convert that Portfile into a Tcl script that can be
> invoked as a standalone command (which can itself be installed through a port, of course).
> That will most likely make it more suitable for future evolution, whereas if you chose to use
> a Portfile now you'll remain stuck with that if you don't want to have to change user habits
> later on (a very bad idea with the user population targeted, I think).

I thought about standalone scripts already. But came to the conclusion that the following command is the cleanest and safest way to add a 3rd party repository from the end user's perspective:

  sudo port install <3rd_party_repo_name>

And then to disable the repository with:

  sudo port uninstall <3rd_party_repo_name>


>> precedence) can eliminate any worry that ports are masked from the default MacPorts
>> repository. That is how I wrote my proposed Portfile. I should not and do not want to
>> mask anything from the default repository.
>
> And yet that is exactly what a foreign repo can be useful for, but you'd have a point in
> preventing that kind of usage to (sub)average users.
> Though it'd also make it impossible to "push" an update to a port from the official repo
> that hasn't been updated in ages, and that can act as an alternative for another port
> (there are -devel ports in that situation).
>
>> And 3rd party repositories should not be masking anything, be it Portfiles or RPMs or
>> Debian packages, from default repositories.
>
> I don't agree with that, and a quick look on Ubuntu's LaunchPad will show you there are
> many "PPAs" that do exactly that.

OK, so you indicated two additional use cases:
1) Overriding ports from the default repository.
2) Allowing the equivalent of PPAs.

I think that both of these are possible with the existing MacPorts using my scheme, if not very clean.
And you are right, my statement about "repositories should not be masking anything from default repositories" is too strong for these two cases. I was only thinking that this should not be done by default. I don't want to eliminate the possibility of overriding the default repositories. There should be some mechanism for that and you clearly show there are use cases for it. I would just avoid doing that by default for my use case.


>> MacPorts already has the mechanism to enforce this.
>
> Oh? Good thing it's weak enough not to cause me any grey hairs :)

I was thinking about the order of the URLs in sources.conf. That does enforce the default repository to always be taken first if you add additional URLs to the end of the file, no?

Cheers

Artur