Re: Easy access to external repositories.
On Monday June 01 2015 13:07:45 Clemens Lang wrote: In the long term, this may become easier when (and if) we finish the SAT-solving ^^^ Translation? would be nice to [...] allow per package priority. But I do not know of any other production package management system that has implemented such a thing. Well, looking at Linux for inspiration doesn't mean we have to do everything like them ... Linux (at least APT) allows versioned dependencies, and user selection of the version to be installed for packages that are provided with different versions (even through a standard GUI like Synaptic). MacPorts doesn't have versioned dependencies, and introducing would be hard as far as I understand were there to be willingness (which there isn't, again AFAIU). If it's easy and acceptable to implement port directory priorities as opposed or in addition to repository priorities, that could provide a comparable form of user selection of port versions. Not just from foreign repositories: it's also perfectly possible (and maybe even supported) to have the svn port repository configured as a source of ports that tend to be updated much more frequently than the ones in the standard rsync repo. At least that's the impression I have. If that's not really the case, a per-port priority mechanism would make it possible to use the svn repo as a source for beta-testing certain port updates before pushing them to all users. Am I rambling again? :) R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
RE: Easy access to external repositories.
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 macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Easy access to external repositories.
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
Re: Easy access to external repositories.
Hi, - On 1 Jun, 2015, at 11:27, Artur Szostak aszos...@partner.eso.org wrote: At the moment there does not appear to be any defined mechanism for an end user to easily select or de-select optional 3rd party repositories. In a ticket I opened some time ago (https://trac.macports.org/ticket/46954), I proposed a way to use a Portfile to update the configuration files sources.conf, archive_sites.conf and pubkeys.conf in a controlled manner, to allow inclusion of such a 3rd party repository. I would like the Portfile in that ticket to be added to MacPorts, which I believe would make it much easier for the average user to include an optional 3rd party repository if they so wish. Could we get the core developers to have a look at this solution and get some consensus on the idea. It would be nice to get some closure on the ticket. Thanks. I'm in favor of simplifying the inclusion of 3rd party repositories. The Portfile proposed in the ticket is hack, but since we don't have a standard mechanism to do this at the moment, I think we should accept it. The problem I currently see with an automated approach to add a new repository is the order or priority selection. How would you easily decide (in a user interface) whether the new repository supersedes the standard one or not? In the long term, this may become easier when (and if) we finish the SAT-solving based GSoC project currently running, because that would allow us to have multiple versions of the same port provided from different repositories along with proper priorities. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
RE: Easy access to external repositories.
I'm in favor of simplifying the inclusion of 3rd party repositories. The
Portfile
proposed in the ticket is hack, but since we don't have a standard mechanism
to
do this at the moment, I think we should accept it.
I thought it was a rather clean way to deal with my use case :-)
But sure, what would make it nicer is what I alluded to in a previous email.
How about having MacPorts do what YUM does and read additional 3rd party
repository configuration files from a directory. Something like
${prefix}/local/etc/macports/sources.conf.d/, and
${prefix}/etc/macports/archive_sites.conf.d/ etc. Then I do not have to modify
${prefix}/local/etc/macports/sources.conf, but rather just add or remove a
configuration file from /etc/macports/sources.conf.d/. That would be as clean
as it gets I think and how other package managements systems deal with this use
case.
Of course the implementer would have to define what the prioritisation order
would be for the files under this directory. But I would have the standard
MacPorts repository always take precedence over 3rd party ones by default.
The problem I currently see with an automated approach to add a new repository
is the order or priority selection. How would you easily decide (in a user
interface) whether the new repository supersedes the standard one or not?
Should the user interface not simply expose the rules that are already encoded
in the core system? Specifically URLs declared first in the configuration files
take precedence over URLs declared further down.
In the long term, this may become easier when (and if) we finish the
SAT-solving
based GSoC project currently running, because that would allow us to have
multiple versions of the same port provided from different repositories along
with proper priorities.
Hmm.. well, that would be nice to try solve the generic problem and allow per
package priority. But I do not know of any other production package management
system that has implemented such a thing. So I would have to say that this is
probably years away from stable production. Just look at the MacPorts GUI app,
that got started as a GSoC project in 2009 and is still announced as only a
beta product (https://trac.macports.org/wiki/MacPortsGUI).
Per repository prioritisation is already implemented in MacPorts, and a SAT
solver should be able to easily go from per repository prioritisation to per
package prioritisation when it arrives in the future.
Cheers
Artur
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Easy access to external repositories.
On Monday June 01 2015 09:27:11 Artur Szostak wrote: Hi, 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. 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. 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. PS: `port search foo` already lists the various versions of ports matching foo that are known, so the base functionality is already there. 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). R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Easy access to external repositories.
Dear MacPorts developers, At the moment there does not appear to be any defined mechanism for an end user to easily select or de-select optional 3rd party repositories. In a ticket I opened some time ago (https://trac.macports.org/ticket/46954), I proposed a way to use a Portfile to update the configuration files sources.conf, archive_sites.conf and pubkeys.conf in a controlled manner, to allow inclusion of such a 3rd party repository. I would like the Portfile in that ticket to be added to MacPorts, which I believe would make it much easier for the average user to include an optional 3rd party repository if they so wish. Could we get the core developers to have a look at this solution and get some consensus on the idea. It would be nice to get some closure on the ticket. Thanks. Kind regards. Artur ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
RE: Easy access to external repositories.
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? That is what I was thinking, yes. One could have more than one repository per Portfile if you really want. But I think it is reasonable to have 1 Portfile per external repository in most cases. Did you handle deactivation or did you simply make it impossible. The update of the configuration files is handled during the activation phase and rolled-back during deactivation. So it should all be handled. Deactivating the port should get you back to the same state as if the port was never installed in the first place. If this is not the case then I should fix it :-) Of course, a user could always break something by making some very weird modifications to the configuration files directly. But I think I have handled all reasonable scenarios. 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. OK, so add-port-repository would ship with the MacPorts core? 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 Are we still talking about the same thing? I was thinking that implementing the SAT-solver based solution might take a while. Cheers Artur ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Easy access to external repositories.
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. rjvber...@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@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Easy access to external repositories.
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@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] #43758: eero-devel @3.2.2012-11-18: Cannot stat: .../lang/eero-devel/files/llvm-bin, No such file or directory
On 18 May 2015, at 05:42, MacPorts nore...@macports.org wrote: #43758: eero-devel @3.2.2012-11-18: Cannot stat: .../lang/eero-devel/files/llvm- bin, No such file or directory ---+- Reporter: ryandesign@… | Owner: vince@… Type: defect| Status: closed Priority: Normal| Milestone: Component: ports |Version: 2.2.1 Resolution: fixed | Keywords: Port: eero-devel| ---+- Changes (by ryandesign@…): * status: new = closed * resolution: = fixed Comment: Yes, the (10.7 and later) buildbots built this version successfully. Sorry for being very late on this. Blame my Internet provider. This port should be unplugged anyway, as the developer has tossed it. He said eero became irrelevant the day Swift was released. Vincent ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Easy access to external repositories.
Hi,
But sure, what would make it nicer is what I alluded to in a previous email.
How
about having MacPorts do what YUM does and read additional 3rd party
repository
configuration files from a directory. Something like
${prefix}/local/etc/macports/sources.conf.d/, and
${prefix}/etc/macports/archive_sites.conf.d/ etc. Then I do not have to modify
${prefix}/local/etc/macports/sources.conf, but rather just add or remove a
configuration file from /etc/macports/sources.conf.d/. That would be as clean
as it gets I think and how other package managements systems deal with this
use
case.
Good point, we should implement this.
Of course the implementer would have to define what the prioritisation order
would be for the files under this directory. But I would have the standard
MacPorts repository always take precedence over 3rd party ones by default.
The file could just contain priority metadata to do this correctly.
Should the user interface not simply expose the rules that are already encoded
in the core system? Specifically URLs declared first in the configuration
files
take precedence over URLs declared further down.
Yes -- but an ordered list with operations to re-order it is hard to represent
in
a command line interface :(
Hmm.. well, that would be nice to try solve the generic problem and allow per
package priority. But I do not know of any other production package management
system that has implemented such a thing.
Most Linux package managers have priorities associated with repositories. We're
currently planning to use libsolv, which is also used by yum and provides this
feature.
So I would have to say that this is probably years away from stable
production.
I wouldn't say year*s*, but a year is probably a realistic estimate, so this is
not a valid short-term solution, which is why I'm in favor of committing your
Portfile.
Just look at the MacPorts GUI app, that got started as a GSoC project in 2009
and is still announced as only a beta product
(https://trac.macports.org/wiki/MacPortsGUI).
Yes, we've previously had problems getting our GSoC projects integrated. We've
made process adjustments that should improve this situation, though.
--
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Easy access to external repositories.
Le 01/06/2015 15:26, Clemens Lang a écrit : Of course the implementer would have to define what the prioritisation order would be for the files under this directory. But I would have the standard MacPorts repository always take precedence over 3rd party ones by default. The file could just contain priority metadata to do this correctly. Hi, 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 starting with 20_, the local admin is free to move or add files in the range 00_ to 10_. Regards, Thibaut. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
RE: Easy access to external repositories.
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 ___ macports-dev mailing list macports-dev@lists.macosforge.org
RE: Easy access to external repositories.
Well, looking at Linux for inspiration doesn't mean we have to do everything like them ... Linux (at least APT) allows versioned dependencies, and user selection of the version to be installed for packages that are provided with different versions (even through a standard GUI like Synaptic). Sure. I was just thinking that since this hasn't been done before, it is going to have a higher risk and likely take longer to bring to market. So the SAT solver approach would be nice, but probably not feasible within the next year, or two, or however long it would take to bring to production grade. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Easy access to external repositories.
- On 1 Jun, 2015, at 14:35, René J.V. Bertin rjvber...@gmail.com wrote: On Monday June 01 2015 13:07:45 Clemens Lang wrote: In the long term, this may become easier when (and if) we finish the SAT-solving ^^^ Translation? http://en.wikipedia.org/wiki/Boolean_satisfiability_problem http://www.mancoosi.org/papers/leberre-sat-beyond.pdf Basically, the problem of resolving dependencies can be mapped to a SAT problem, which can be solved and optimized using a standard SAT solver. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
RE: Easy access to external repositories.
Hmm.. well, that would be nice to try solve the generic problem and allow per package priority. But I do not know of any other production package management system that has implemented such a thing. Most Linux package managers have priorities associated with repositories. We're currently planning to use libsolv, which is also used by yum and provides this feature. OK, but the Linux package managers do it on the per repository level, not the per package level, right? My understanding is that you were thinking about going to the per package level with the prioritisation. So I would have to say that this is probably years away from stable production. I wouldn't say year*s*, but a year is probably a realistic estimate, so this is not a valid short-term solution, which is why I'm in favor of committing your Portfile. So if its mimicking what YUM does, yeah, true, it should be quicker. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
RE: Easy access to external repositories.
Did you handle deactivation or did you simply make it impossible. The update of the configuration files is handled during the activation phase and rolled-back during deactivation. So it should all be handled. Deactivating the port should get you back to the same state as if the port was never installed in the first place. If this is not the case then I should fix it :-) Of course, a user could always break something by making some very weird modifications to the configuration files directly. But I think I have handled all reasonable scenarios. Yeah? How do you handle % port install repositoryA % port install repositoryB % port deactivate|uninstall repositoryA Do you roll back to the state from before installing repo A, removing repo B at the same time? No, repositoryB stays in place. I only remove what was added during port install repositoryA. I append configuration strings to the files during pre-activate and use reinplace with appropriate regular expressions to remove what was previously added during post-deactivate. Have a look at the Portfile for details: https://trac.macports.org/attachment/ticket/46954/Portfile.2 Of course, if MacPorts was reading configuration directories like has been discussed already, then this could all be cleaner, because I just install and remove whole files rather than modify existing ones. Cheers Artur ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
RE: Easy access to external repositories.
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? In short, for some of the same reasons that repositories like Fedora EPEL and other 3rd party repositories exist. In our case: we have a community of astronomers that have requested a distribution mechanism for ESO software via MacPorts, which they are familiar with. However, our software is only relevant to astronomers (a few hundred users), rather than the much larger community that the default MacPorts repository it trying to target. So I thought that taking an optional extra repository approach (kind of like Fedora EPEL) would be the most appropriate. Another issue would be any differences between our release cycle at ESO versus the default MacPorts repository one. I just don't know how compatible these are at the moment. For the time being, it is lower risk for our astronomers for ESO to maintain its own package repository, which it has full control over. Would it nevertheless make sense to push our changes to the default MacPorts repository in the future? Perhaps. We have considered it and will likely revisit this idea again down the line. All this has been working fine except for one issue: many of our astronomers get a bit lost when trying to setup our repository in the sources.conf, archive_sites.conf etc. So I thought the best would be to use a Portfile to setup our ESO repository automatically if (and only if) requested by the user. Thus, making the repository optional. This would be a similar idea to what I see with RPMs used to setup 3rd party YUM repositories. Ultimately my goal is that the astronomy user should be able to do the following from a freshly installed MacPorts system: sudo port install esorepo sudo port sync sudo port install ESO specific package These would be commands that they are familiar with and can understand. Kind regards. Artur ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Easy access to external repositories.
On Monday June 01 2015 16:57:39 Artur Szostak wrote: Did you handle deactivation or did you simply make it impossible. The update of the configuration files is handled during the activation phase and rolled-back during deactivation. So it should all be handled. Deactivating the port should get you back to the same state as if the port was never installed in the first place. If this is not the case then I should fix it :-) Of course, a user could always break something by making some very weird modifications to the configuration files directly. But I think I have handled all reasonable scenarios. Yeah? How do you handle % port install repositoryA % port install repositoryB % port deactivate|uninstall repositoryA Do you roll back to the state from before installing repo A, removing repo B at the same time? That's just the easiest case, there are probably more complicated scenarios where the user didn't touch any configuration file directly ... OK, so add-port-repository would ship with the MacPorts core? Not necessarily, it could be installed through a port itself (cf. port-depgraph or port-whatsnew, http://svn.macports.org/repository/macports/contrib/port-whatsnew). Are we still talking about the same thing? I was thinking that implementing the SAT-solver based solution might take a while. Ah, the general implementation of that, sure, that's possible. I was just talking about the implementation of per-port priorities on top of the current (or revamped) per-repo priorities. And I could be wrong :) R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Easy access to external repositories.
In our case: we have a community of astronomers that have requested a distribution mechanism for ESO software via MacPorts, which they are familiar with. However, our software is only relevant to astronomers (a few hundred users), rather than the much larger community that the default MacPorts repository it trying to target. A few hundred users may well be more than the majority of ports have, actually! So I thought that taking an optional extra repository approach (kind of like Fedora EPEL) would be the most appropriate. Another issue would be any differences between our release cycle at ESO versus the default MacPorts repository one. I just don't know how compatible these are at the moment. For the time being, it is lower risk for our astronomers for ESO to maintain its own package repository, which it has full control over. Would it nevertheless make sense to push our changes to the default MacPorts repository in the future? Perhaps. We have considered it and will likely revisit this idea again down the line. If you are the maintainer, you should be able to have as much control as you wish over the Portfiles and the release cycle. There is no release cycle for ports really, you can just update them whenever you please. David ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Easy access to external repositories.
On 2015-06-01 15:26, Clemens Lang wrote:
But sure, what would make it nicer is what I alluded to in a previous email.
How
about having MacPorts do what YUM does and read additional 3rd party
repository
configuration files from a directory. Something like
${prefix}/local/etc/macports/sources.conf.d/, and
${prefix}/etc/macports/archive_sites.conf.d/ etc. Then I do not have to
modify
${prefix}/local/etc/macports/sources.conf, but rather just add or remove a
configuration file from /etc/macports/sources.conf.d/. That would be as clean
as it gets I think and how other package managements systems deal with this
use
case.
Good point, we should implement this.
Furthermore, it would probably be better to have only one file for
everything we configure separately in sources.conf, archive_sites.conf,
and pubkeys.conf at the moment. This would make it easier to add an
additional ports tree with binary archives.
Just look at the MacPorts GUI app, that got started as a GSoC project in 2009
and is still announced as only a beta product
(https://trac.macports.org/wiki/MacPortsGUI).
Yes, we've previously had problems getting our GSoC projects integrated. We've
made process adjustments that should improve this situation, though.
We still have other branches of GSoC projects lying around that were
finished to 90%, but then nobody integrated and merged the code back to
trunk. Often the students promise to finish their work even after the
summer, but it rarely happens.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
RE: Easy access to external repositories.
If you are the maintainer, you should be able to have as much control as you wish over the Portfiles and the release cycle. There is no release cycle for ports really, you can just update them whenever you please. That will be useful input when we discuss it again at ESO. One other thing that came to mind: how could we control the binary package archive? How does one make sure binary packages are available at the same time as the Portfile is updated? Currently we release prebuilt binary packages together with any Portfile updates at the same time to our repository. But that is because we control the FTP that stores all these files. Regards. Artur ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [136972] trunk/dports/gis/cgal/Portfile
On Jun 1, 2015, at 11:13 AM, vi...@macports.org wrote: Revision 136972 Author vi...@macports.org Date 2015-06-01 09:13:16 -0700 (Mon, 01 Jun 2015) Log Message cgal: bump to 4.6 Modified Paths • trunk/dports/gis/cgal/Portfile Diff Modified: trunk/dports/gis/cgal/Portfile (136971 = 136972) --- trunk/dports/gis/cgal/Portfile2015-06-01 15:02:56 UTC (rev 136971) +++ trunk/dports/gis/cgal/Portfile2015-06-01 16:13:16 UTC (rev 136972) -master_siteshttps://gforge.inria.fr/frs/download.php/latestfile/2743/ +master_sites https://gforge.inria.fr/frs/download.php/file/34705/CGAL-4.6.tar.xz Should just be: master_siteshttps://gforge.inria.fr/frs/download.php/file/34705/ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [136972] trunk/dports/gis/cgal/Portfile
Ryan, On 01 Jun 2015, at 19:24, Ryan Schmidt ryandes...@macports.org wrote: master_siteshttps://gforge.inria.fr/frs/download.php/file/34705/ Thanks. Done in r136973. Sorry for the flub. Vincent ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Easy access to external repositories.
Provided the licenses for your software and its dependencies would make the binaries redistributable, the binaries will be built automatically for the default variants by the buildslaves (using various recent versions of OSX) after a commit of a Portfile to the MacPorts repository, and then those binaries will be available for users when they run 'port install'. David On Mon, Jun 1, 2015 at 2:24 PM, Artur Szostak aszos...@partner.eso.org wrote: If you are the maintainer, you should be able to have as much control as you wish over the Portfiles and the release cycle. There is no release cycle for ports really, you can just update them whenever you please. That will be useful input when we discuss it again at ESO. One other thing that came to mind: how could we control the binary package archive? How does one make sure binary packages are available at the same time as the Portfile is updated? Currently we release prebuilt binary packages together with any Portfile updates at the same time to our repository. But that is because we control the FTP that stores all these files. Regards. Artur ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Easy access to external repositories.
On Mon, Jun 1, 2015 at 4:54 PM, Artur Szostak aszos...@partner.eso.org wrote: What is the duty cycle or delay for the buildslaves to build these packages? I have seen a number of occasions where MacPorts cannot seem to find the binary for a Portfile from the default repository and builds the package locally. Most often that's because there is a license conflict. (Some of these don't actually exist; for example, ports that require ld64 for linking often falsely claim a license conflict as a result. Those are getting cleaned up as they are found.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Easy access to external repositories.
The buildslaves begin shortly after each commit. The delay, if any, is probably a few minutes. Of course depending on how long it takes to build the ports it may take a while to finish, and may have been busy building other ports already when you commit. When it cannot get the binary, that may be because of license issues, because the build failed on the buildslave, or because you are using non-default variants (and probably other reasons too). On Mon, Jun 1, 2015 at 4:54 PM, Artur Szostak aszos...@partner.eso.org wrote: Our software is all open source (GPL) so thats not the problem. What is the duty cycle or delay for the buildslaves to build these packages? I have seen a number of occasions where MacPorts cannot seem to find the binary for a Portfile from the default repository and builds the package locally. -- *From:* dstru...@gmail.com [dstru...@gmail.com] on behalf of David Strubbe [dstru...@macports.org] *Sent:* 01 June 2015 21:06 *To:* Artur Szostak *Cc:* MacPorts Development *Subject:* Re: Easy access to external repositories. Provided the licenses for your software and its dependencies would make the binaries redistributable, the binaries will be built automatically for the default variants by the buildslaves (using various recent versions of OSX) after a commit of a Portfile to the MacPorts repository, and then those binaries will be available for users when they run 'port install'. David ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Fwd: Re: cloudflare/zlib on OS X
FYI, I was (most likely) right: without that 1 file with a GPL license the CloudFlare patches won't change the zlib license. R. -- Forwarded Message -- Subject: Re: cloudflare/zlib on OS X Date: Monday June 01 2015, 19:55:45 From: Vlad Krasnov v...@cloudflare.com To: René J.V. Bertin rjvber...@gmail.com We didn’t change the license. I am sure if you remove the other files, the original zlib license will apply. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
RE: Easy access to external repositories.
Our software is all open source (GPL) so thats not the problem. What is the duty cycle or delay for the buildslaves to build these packages? I have seen a number of occasions where MacPorts cannot seem to find the binary for a Portfile from the default repository and builds the package locally. From: dstru...@gmail.com [dstru...@gmail.com] on behalf of David Strubbe [dstru...@macports.org] Sent: 01 June 2015 21:06 To: Artur Szostak Cc: MacPorts Development Subject: Re: Easy access to external repositories. Provided the licenses for your software and its dependencies would make the binaries redistributable, the binaries will be built automatically for the default variants by the buildslaves (using various recent versions of OSX) after a commit of a Portfile to the MacPorts repository, and then those binaries will be available for users when they run 'port install'. David ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: cloudflare/zlib on OS X
On Jun 1, 2015, at 5:11 PM, René J.V. Bertin rjvber...@gmail.com wrote: I was (most likely) right: without that 1 file with a GPL license the CloudFlare patches won't change the zlib license. Where do they explicitly license their contributions under the zlib license? vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: cloudflare/zlib on OS X
On Monday June 01 2015 18:00:29 Lawrence Velázquez wrote: Where do they explicitly license their contributions under the zlib license? They don't explicitly change the licensing of the files they modify. If those files each carry a zlib license they will still carry that license after applying the patch. CloudFlare are the only ones who could accuse someone of stealing their code, applying the wrong license etc. I forwarded a statement from a CloudFlare employee using his work address that they didn't change a license. What more could you want?! R ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GSoC Project: Revitalizing Pallet
Hey Ian, René, and Kevin, Well, Kyle, if you are interested, I could send you the code of Fossick and a specification/design document. You would be welcome to re-use any of it or any of the ideas contained in it Thanks for the offer, Ian! I'm working on getting the darn thing to compile on modern versions of OS X first, then I'll be considering different options and moving forward there. I'll definitely keep your offer in mind, and I'll make sure to reach out to the community before I do anything too crazy to make sure it's what we really want/need. :) I think that such a GUI should not be alone. It must be complemented (and maybe even preceded) by a launcher, akin to the tools providing Start Button like functionality on Linux desktops, but that would sit in the Dock on OS X. Interesting idea, René. I'll make sure to keep it in mind! It would be great if Pallet developed into a viable, ongoing GUI client for the MacPorts project. My guess is that it will need a lot of work, and ongoing maintenance from a single owner or team, to get there. From what I can tell, you're pretty much on the money, Kevin. It'll be a lot of work, and hopefully either myself, or some other fearless developers, will be able to keep it up and maintain it after the summer is over. Thanks!, -Kyle ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: cloudflare/zlib on OS X
Did you verify that this employ is actually empowered to dictate the company's licensing? On Jun 1, 2015, at 8:52 PM, René J.V. Bertin wrote: They don't explicitly change the licensing of the files they modify. If those files each carry a zlib license they will still carry that license after applying the patch. CloudFlare are the only ones who could accuse someone of stealing their code, applying the wrong license etc. I forwarded a statement from a CloudFlare employee using his work address that they didn't change a license. What more could you want?! ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GSoC Project: Revitalizing Pallet
Hi Kyle, On 02/06/2015, at 11:15 AM, Kyle Sammons wrote: Ian wrote: Well, Kyle, if you are interested, I could send you the code of Fossick and a specification/design document. You would be welcome to re-use any of it or any of the ideas contained in it Thanks for the offer, Ian! I'm working on getting the darn thing to compile on modern versions of OS X first, then I'll be considering different options and moving forward there. I'll definitely keep your offer in mind, and I'll make sure to reach out to the community before I do anything too crazy to make sure it's what we really want/need. :) Watch out for the evolutionary changes in Cocoa/OSX/ObjectiveC across successive versions of OS X !!! I was particularly having problems figuring out exactly what to write and for which OS X, in the light of *major* changes in: - Dynamic storage management (DIY vs. garbage-collect vs. reference-counting), - The GUI designer (Interface Builder) and its relationships (or links) to generated and hand-written chunks of code. Fundamental stuff. It did not help that I was also teaching myself Objective C… :-) nor that I have been designing and coding for various GUI and forms designers for about 40 years now. Each one is or was unique in its own way. Maybe Pallet won't even work with newer versions of Xcode, even if you can compile it. Pallet code is quite old now. I was (and still am) using Lion (OS X 10.7.5) and Xcode 4.6.1 and do not remember any particular problems compiling Pallet. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
