>> make it much easier for the average user to include an optional 3rd party >> repository if they so wish. > > I'm not sure if 3rd party repositories are something for the average user, > when average is taken > from a population where the majority don't know how to edit a configuration > file by hand.
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: sudo port install <name_of_3rd_party_repo> sudo port sync i.e. the same commands that an end user is already used to. > The idea isn't bad, but I think there should first be changes to base that > make it clear > when a 3rd party port masks an updated version in the standard repository, as > well as > to let PortGroup files apply beyond the repository they're in (if that's not > the default repo). > There are probably other things that could be considered as well to help the > average > user AND the port maintainers who'll undoubtedly get to resolve issues > related to > masked ports. The precedence/ordering of Portfiles is already defined. It is the order in which the repository URLs appear in the sources.conf and archive_sites.conf files. Thus, masking of ports is deterministic and predictable. A simple policy of always appending 3rd party URLs to the end of the configuration files (i.e. the default public repository always takes 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. 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. > I see this kind of functionality more of a feature for a port/package manager > GUI, > the way the Linux counterparts (synaptic, muon, etc) allow to manage the > source > repositories. OK, but MacPorts still does not have a production version of a GUI. If we want to use Linux as an example, let us consider Fedora and what they do with YUM. From what I understand, my use case is typically handled by preparing a RPM that will install a repository configuration file under /etc/yum.repos.d/. After installing this RPM, the user gets access to all subsequent RPMs that are in that 3rd party repository. Replace Portfile for RPM and I believe my scheme is replicating what is done with YUM. 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. > PS2: How feasible would it be to add a possibility to override the normal > Portfile > resolution on a port-by-port basis? That'd probably be required too for the > average > user who would want to use a specific port (or 2) from a 3rd party repo but > not others > that he wants to use from another repo (esp. when that other repo is the > official repo). 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. If users want some blend (I think they are power users at that point), then they can already do this, but have to create their own intermediate repository. And 3rd party repositories should not be masking anything, be it Portfiles or RPMs or Debian packages, from default repositories. MacPorts already has the mechanism to enforce this. Cheers Artur _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
