On Monday June 01 2015 11:35:59 Artur Szostak wrote: > 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 . 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? 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. 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). > 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). > Also, don't PortGroup files already work beyond the repository that they > reside in. I believe I have been able to successfully use some PortGroups > from the main public repository in my own Portfiles without problems. Yes, as I said PortGroups apply to their local repository except when they're in the default repository, which is where PortGroup definitions are expected to be found if they're not in the local repo. > If you want, a nice improvement for MacPorts would be if (like YUM on Fedora) > it doesn't just look for a file sources.conf, but also for a directory, e.g. > /opt/local/etc/macports/sources.conf.d/ in which 3rd party repository > configurations can be added or removed. I reached the same conclusion above (but see the caveat). This makes it easier to add, add, remove, add again, remove again etc. because each addition is in an independent file. > OK, so I would say that this kind of a game starts being an overkill for > average users. I do not think YUM or APT do this. You add a whole 3rd party > repository or you don't. No, they don't. But I think there are many more foreign repos "out there" for Linux, often set up specifically to add (or replace!) just a few packages. Ubuntu at least makes it easy to create new PPAs once you've gone through the process to make your first, and its mechanism contains both a security layer you cannot (easily) circumvent and a way to roll back any changes you made by adding a ppa (ppa-purge). Also, I wouldn't be surprised if the user population using Linux is more savvy overall than the one using Mac OS X. (I'm all for not under-estimating one's users, but there are times that means you cannot over-estimate their left-handedness enough ;)). The thing with MacPorts is that at least until now there is nothing to streamline the use of other repositories. I think that practice will show that many users who build their own repo start out doing so because they miss a port, but end up adding ports that override the ones from the official repo because of requirements of their own ports, or simple of their own workflow. That's how mine has been growing, to a point where it also contains copies of patched files from base. And it's available online via git, so probably a candidate to be added through whatever easy mechanism is going to be implemented, as long as that doesn't include a vetting/filtering feature. > 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. > MacPorts already has the mechanism to enforce this. Oh? Good thing it's weak enough not to cause me any grey hairs :) R _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
