Re: Questions on port development
On Mar 25, 2018, at 09:57, Joshua Root wrote: > A port with no destroot phase will install no files. I doubt that is > what you want. Well it's technically possible to write a port that performs the destroot tasks in an earlier phase. We'd prefer a port not do this, but some build systems are very insistent about building and destrooting together, and in that case the port might do the combined build-and-destroot in either the build phase or in the destroot phase, at the discretion of the port author. We have a very small number of ports that do that.
Re: platforms
On 2018-03-24 13:54, Jan Starý wrote: > The 'platforms' field of a Portfile is currently > both _required_ and _ignored_. By the Guide, > > A list of the platforms on which the port has been tested. > Required, but not interpreted in any way by the software > at this time; it is purely informational for user > Also, it is allowed to say .e.g. "freebsd" but not e.g. "openbsd". > I propose that the 'platforms' field be no longer required > if it is ignored, and if it stays, let it be a free form text, > as opposed to a predefined definitive list of all unixes. I see the list of possible values in the guide as examples and non-exhaustive. The wording could be better, though. > Better yet, drop it altogether. The fact that I tested on Solaris > or Debian means nothing regarding the MP port. I have also tested > it on darwin of course, but that goes without saying. As the guide says, it is "informational" at the moment. In the past, more people were using MacPorts on FreeBSD, therefore they added their test results to the port. I agree it could be optional for the common case of "platforms darwin" without any specific requirements on the version. > (What would be kinda useful is if it pointed to the actual _ports_ > on the other systems - often there are things we can learn, as they > battle a lot of the same GNUisms etc. For example, the patch for opus > https://github.com/macports/macports-ports/pull/1217 is basically > the OpenBSD patch for opus. So if opus 'platforms' pointed to > http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/audio/opus/ > it would be usefull. Unlike now.) If a specific patch was taken from another distribution, information should be right in the patch file. Some ports are already using "Upstream:" or "Upstream-Status:" header lines in the patches. There is no formal format for MacPorts, but it was loosely adopted from OpenEmbedded [1]. I do not want to keep a list of all other package managers providing libopus. There is already repology for this [2]. Rainer [1] https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations:_Upstream-Status [2] https://repology.org/metapackage/opus/versions
Re: Questions on port development
On 2018-03-25 16:19, macpo...@parvis.nl wrote: > I'm working on a port for munin 2 as the current macports version 1.4.7 is of > 14 mar 2012. > The munin-node seems to work fine, the server part requires more testing. Great! That port is really in the need of an update. > (1) > > I need a port install munin@2.0.35 buth without a destroot phase. > Is there a dummy command for destroot.cmd that allows to build without > install? exit 1? For testing, you can run the various port phases separately. Running 'sudo port -v build' would only complete the build phase and you can examine the results in the work/ directory, which is available via the work symlink next to the Portfile, or with 'port work'. You can also run 'sudo port destroot' and examine the files that would be installed at work/destroot/. > (2) > > To prevent clashes with the current macports installation, I think it is best > to create a second one. > > Guide 2.2.4 Install Multiple MacPorts Copies ( > https://guide.macports.org/#installing.macports.source.multiple ) talks about > that. I assume that 2.2.3 Git Install should be done before. confirmation > please. This is usually not required for port development, unless you do not want to uninstall the existing munin port. > (3) > > If I succeed in making this port, how should I do it? > - create new port munin2 with no relation to munin @1.4.7 > - make this an upgrade for the current version. I see no reason to keep 1.x around. On a quick check, most other distributions are also only providing 2.x. Rainer
Re: Questions on port development
On 2018-3-26 01:19 , macpo...@parvis.nl wrote: > I'm working on a port for munin 2 as the current macports version 1.4.7 is of > 14 mar 2012. > The munin-node seems to work fine, the server part requires more testing. > > (1) > > I need a port install munin@2.0.35 buth without a destroot phase. > Is there a dummy command for destroot.cmd that allows to build without > install? exit 1? A port with no destroot phase will install no files. I doubt that is what you want. > (2) > > To prevent clashes with the current macports installation, I think it is best > to create a second one. > > Guide 2.2.4 Install Multiple MacPorts Copies ( > https://guide.macports.org/#installing.macports.source.multiple ) talks about > that. I assume that 2.2.3 Git Install should be done before. confirmation > please. You don't have to use git (and you probably don't want to install from master anyway). You can build from the release tarball. > (3) > > If I succeed in making this port, how should I do it? > - create new port munin2 with no relation to munin @1.4.7 > - make this an upgrade for the current version. Hard to answer without being familiar with munin. Is there a reason why someone would want to stick with munin 1.x instead of upgrading to the current version? - Josh
Questions on port development
I'm working on a port for munin 2 as the current macports version 1.4.7 is of 14 mar 2012. The munin-node seems to work fine, the server part requires more testing. (1) I need a port install munin@2.0.35 buth without a destroot phase. Is there a dummy command for destroot.cmd that allows to build without install? exit 1? (2) To prevent clashes with the current macports installation, I think it is best to create a second one. Guide 2.2.4 Install Multiple MacPorts Copies ( https://guide.macports.org/#installing.macports.source.multiple ) talks about that. I assume that 2.2.3 Git Install should be done before. confirmation please. (3) If I succeed in making this port, how should I do it? - create new port munin2 with no relation to munin @1.4.7 - make this an upgrade for the current version. thanks, paul de vries.
Heads-up: PROJ
Hey there,
I’m going to commit a major overhaul to the “proj” port. Currently, “proj” is
split between proj47 and proj, the latter corresponding to proj 5.0.0 recently
released.
The problem is this:
• Proj 5.0.0 is buggy, unusable at least with QGis until a bugfix version is
out;
• Proj and proj47 can be installed together, but since proj installs its files
in ${prefix} whereas proj47 does in ${prefix}/lib/proj${version}/…, even if
proj47 location is specified in the Portfile, because of the order in which -I…
include paths are emitted at compile time, the compiler ends up seeing always
proj include files instead of proj47;
• Proj47 is obsolete, latest proj4 version is 4.9.3.
What I am going to do:
• Rename proj47 port into proj4 and update it to proj 4.9.3;
• Change the proj Portfile so that it installs files in ${prefix}/lib/proj5, in
such a way that both proj4 and proj(5) can be used simultaneously without
conflicting;
• Update all portfiles that currently depend on proj → proj4, until a suitable
proj 5 bug fix version is released.
What I could do:
• Rename proj into proj5. Does anyone objects to this?
Cheers
Vincent
Re: platforms
On Mar 25, 2018, at 01:49, Jan Stary wrote: > On Mar 24 14:14:37, Mojca wrote: >> On 24 March 2018 at 13:54, Jan Starý wrote: >>> The 'platforms' field of a Portfile is currently >>> both _required_ and _ignored_. By the Guide, >>> >>>A list of the platforms on which the port has been tested. >>>Required, but not interpreted in any way by the software >>>at this time; it is purely informational for users. >> >> I don't know anything about this, but it's possible that this could be >> interpreted already, or maybe soon in the future. > > Does anybody know if it is interpretd then? Guide says no. As far as I know, the platforms variable is not currently used. >>> Also, it is allowed to say .e.g. "freebsd" but not e.g. "openbsd". >> >> Personally I don't see any reason for not allowing "openbsd" (other >> than the fact that only two ports will have that keyword, so it will >> probably be useless at the end). > > It _is_ completely useless now, whatever you put there. > >>> I propose that the 'platforms' field be no longer required >>> if it is ignored, and if it stays, let it be a free form text, >>> as opposed to a predefined definitive list of all unixes. >> >> We'll need it to specify which darwin versions are supported. > > That would totaly change the meaning, > requiring a change of that filed for each and every port. > In fact, making a lot of current content illegal. Obviously if we go forward with the plan of reusing the platforms variable as a way to signify which versions of OS are acceptable, it will be done in such a way that the values ports are currently using for that variable are not considered illegal. >> We currently have this ticket high on our priority list: >>https://trac.macports.org/ticket/15712 > > That's ten years old, and "there's no code written yet" > as of 13 days ago. We are aware. It is a feature we have wanted for a long time, and it was recently decided that we should perhaps finally try to do something about it.
Re: platforms
On 25 March 2018 at 08:49, Jan Stary wrote: > On Mar 24 14:14:37, mojca.miklavec.li...@gmail.com wrote: >> >> We currently have this ticket high on our priority list: >> https://trac.macports.org/ticket/15712 > > That's ten years old, and "there's no code written yet" > as of 13 days ago. https://github.com/macports/macports-base/pull/68 Mojca
Re: platforms
On Mar 24 14:14:37, mojca.miklavec.li...@gmail.com wrote: > On 24 March 2018 at 13:54, Jan Starý wrote: > > The 'platforms' field of a Portfile is currently > > both _required_ and _ignored_. By the Guide, > > > > A list of the platforms on which the port has been tested. > > Required, but not interpreted in any way by the software > > at this time; it is purely informational for users. > > I don't know anything about this, but it's possible that this could be > interpreted already, or maybe soon in the future. Does anybody know if it is interpretd then? Guide says no. > > Also, it is allowed to say .e.g. "freebsd" but not e.g. "openbsd". > > Personally I don't see any reason for not allowing "openbsd" (other > than the fact that only two ports will have that keyword, so it will > probably be useless at the end). It _is_ completely useless now, whatever you put there. > > I propose that the 'platforms' field be no longer required > > if it is ignored, and if it stays, let it be a free form text, > > as opposed to a predefined definitive list of all unixes. > > We'll need it to specify which darwin versions are supported. That would totaly change the meaning, requiring a change of that filed for each and every port. In fact, making a lot of current content illegal. > We currently have this ticket high on our priority list: > https://trac.macports.org/ticket/15712 That's ten years old, and "there's no code written yet" as of 13 days ago. Jan > > Better yet, drop it altogether. The fact that I tested on Solaris > > or Debian means nothing regarding the MP port. I have also tested > > it on darwin of course, but that goes without saying. > > > > (What would be kinda useful is if it pointed to the actual _ports_ > > on the other systems - often there are things we can learn, as they > > battle a lot of the same GNUisms etc. For example, the patch for opus > > https://github.com/macports/macports-ports/pull/1217 is basically > > the OpenBSD patch for opus. So if opus 'platforms' pointed to > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/audio/opus/ > > it would be usefull. Unlike now.) > > You could (should?) provide such pointers in comments. > I always include sources of patches (or links to upstream tickets) if > I get them elsewhere, either in Portfile or in the patch itself. > > Mojca
