Re: [33798] trunk/dports/mail
On Feb 5, 2008, at 08:38, simon@macports.org wrote:
Revision: 33798 http://trac.macosforge.org/projects/macports/changeset/33798 Author: simon@macports.org Date: 2008-02-05 06:38:46 -0800 (Tue, 05 Feb 2008)
Log Message: ----------- mail/uagen: New port.
Since it doesn't seem to install any compiled software, I think it needs a "universal_variant no" bit.
On Tue, Feb 05, 2008 at 11:29:37AM -0600, Ryan Schmidt wrote:
Since it doesn't seem to install any compiled software, I think it needs a "universal_variant no" bit.
Thanks for your hint. I just added it. Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229
Simon Ruderich wrote:
On Tue, Feb 05, 2008 at 11:29:37AM -0600, Ryan Schmidt wrote:
Since it doesn't seem to install any compiled software, I think it needs a "universal_variant no" bit.
Thanks for your hint. I just added it.
As this software is just a perl script and requires no extra steps for other architectures shouldn't it considered to be already universal? Which would be: default_variants +universal variant universal {} Rainer
On Feb 5, 2008, at 17:21, Rainer Müller wrote:
Simon Ruderich wrote:
On Tue, Feb 05, 2008 at 11:29:37AM -0600, Ryan Schmidt wrote:
Since it doesn't seem to install any compiled software, I think it needs a "universal_variant no" bit.
Thanks for your hint. I just added it.
As this software is just a perl script and requires no extra steps for other architectures shouldn't it considered to be already universal?
Which would be: default_variants +universal variant universal {}
I would say no. I would say "universal_variant no" is currently appropriate for software that is architecture-agnostic, like this perl script. Though I've never been really happy with "universal_variant no". It's not a Boolean situation. See my earlier message: http://lists.macosforge.org/pipermail/macports-dev/2007-June/001868.html In it, I suggest that "universal_variant" should be replaced with "universal.method" and have several possible values. Actually I don't care so much if it's renamed, but I do care that we support these options: "autoconf" (like "universal_variant yes" today) "lipo" (automated multiple building and merging with lipo [1]) "none" (like "universal_variant no" today) "implicit" (software is already universal and can't be built non- universal) "unknown" (default; same as "autoconf" (if "use_configure yes") or "lipo" (if "use_configure no") but prints a warning that this is untested) I now revise my suggestion in that "none" should be further divided into these two options: "unnecessary" (port is arch-agnostic) "impossible" (port fails when built universal) These names may not be great; suggestions for other names for these options welcomed. For example "lipo" might be better called "merge". [1] I also suggested this in an earlier message: http://lists.macosforge.org/pipermail/macports-dev/2007-April/ 001319.html
Le 6 févr. 08 à 03:42, Ryan Schmidt a écrit :
On Feb 5, 2008, at 17:21, Rainer Müller wrote:
Simon Ruderich wrote:
On Tue, Feb 05, 2008 at 11:29:37AM -0600, Ryan Schmidt wrote:
Since it doesn't seem to install any compiled software, I think it needs a "universal_variant no" bit.
Thanks for your hint. I just added it.
As this software is just a perl script and requires no extra steps for other architectures shouldn't it considered to be already universal?
Which would be: default_variants +universal variant universal {}
I would say no. I would say "universal_variant no" is currently appropriate for software that is architecture-agnostic, like this perl script.
Though I've never been really happy with "universal_variant no". It's not a Boolean situation. See my earlier message:
http://lists.macosforge.org/pipermail/macports-dev/2007-June/ 001868.html
In it, I suggest that "universal_variant" should be replaced with "universal.method" and have several possible values. Actually I don't care so much if it's renamed, but I do care that we support these options:
"autoconf" (like "universal_variant yes" today) "lipo" (automated multiple building and merging with lipo [1]) "none" (like "universal_variant no" today) "implicit" (software is already universal and can't be built non- universal) "unknown" (default; same as "autoconf" (if "use_configure yes") or "lipo" (if "use_configure no") but prints a warning that this is untested)
I now revise my suggestion in that "none" should be further divided into these two options:
"unnecessary" (port is arch-agnostic) "impossible" (port fails when built universal)
These names may not be great; suggestions for other names for these options welcomed. For example "lipo" might be better called "merge".
[1] I also suggested this in an earlier message:
http://lists.macosforge.org/pipermail/macports-dev/2007-April/ 001319.html
I like this. -- Anthony Ramine, the "Ports tree cleaning Maestro". <nox@macports.org>
Ryan Schmidt wrote:
As this software is just a perl script and requires no extra steps for other architectures shouldn't it considered to be already universal?
Which would be: default_variants +universal variant universal {}
I would say no. I would say "universal_variant no" is currently appropriate for software that is architecture-agnostic, like this perl script.
Technically +universal would be 2 (or 4) architectures, while this is for 0 (zero) architectures. That's why it is called "noarch" in some other packaging systems* (that call the universal "fat") Having this "don't need compile" metadata in the Portfile is good, just that "universal" isn't it: http://trac.macports.org/projects/macports/ticket/12206 But it could be joined to a single variable, like Ryan is suggesting, as they do affect eachother ? (if it doesn't have a machine architecture then it doesn't need to have a +universal variant either) --anders * that would be RPM (.noarch.rpm), while another name is used in DEB (.all.deb) difference being how many it is built for, versus how many that it applies to
participants (5)
-
Anders F Björklund
-
N_Ox
-
Rainer Müller
-
Ryan Schmidt
-
Simon Ruderich