Evening everyone!
I'm pleased to announce that MacPorts 1.5.1 has been released
through selfupdate, comprising the following fixes and enhancements:
Release 1.5.1 (11-August-2007 at branches/release_1_5/base's r27646,
by jmpp):
- Remove sed rules taking care of dp based comm
On 10/08/07 20:17, Ryan Schmidt wrote:
> Why are you adding such a variant? Under which circumstances might a user
> want, or not want, to select it? I'm trying to figure out why you don't just
> fetch from CVS all the time, as that would seem to simplify things, wouldn't
> it? Variants are not
Le 11 août 07 à 11:38, Sbranzo a écrit :
On 10/08/07 20:17, Ryan Schmidt wrote:
Why are you adding such a variant? Under which circumstances might
a user
want, or not want, to select it? I'm trying to figure out why you
don't just
fetch from CVS all the time, as that would seem to simplify
Hello,
What is the policy about -devel ports for which their normal
counterparts have a greater or equal version?
% (port echo '*-devel' 1>&2 | sed -E 's/-devel[[:>:]]//') 2>&1 | sort
| xargs port list
Etoile @0.1.9 gnustep/Etoile
Etoile-devel
On 11/08/07 16:58, N_Ox wrote:
>> []
>> ---> Verifying checksum(s) for slrn-devel
>> DEBUG: Executing org.macports.checksum (slrn-devel)
>> ---> Extracting slrn-devel
>> DEBUG: Executing org.macports.extract (slrn-devel)
>> DEBUG: Executing org.macports.patch (slrn-devel)
>> ---> Configuring
I want to use macports to build self contained bundles, containing a
tool and any dependencies of that tool. For example, I want to
distribute an FFTW package that installs into /Users/Shared/FFTW.
Under that directory would be the usual bin, lib etc:
/Users/Shared/FFTW/bin
/Users/Shared/FF
Drew McCormack wrote:
I want to use macports to build self contained bundles, containing a
tool and any dependencies of that tool. For example, I want to
distribute an FFTW package that installs into /Users/Shared/FFTW. Under
that directory would be the usual bin, lib etc:
/Users/Shared/FFTW/
Juan Manuel Palacios <[EMAIL PROTECTED]> writes:
> This is a new feature in MacPorts 1.5.1 to detect violations of the
>pre-established hierarchy that governs the ${prefix} tree, so as to
>keep a sense of order when installing software. In order to minimize
>conflicts with the bundled A
On Aug 11, 2007, at 04:38, Sbranzo wrote:
I think you would need something like this:
pre-configure {
system "cd ${worksrcdir} && autopoint -f"
system "cd ${worksrcdir} && aclocal -I autoconf"
system "cd ${worksrcdir} && autoheader"
From what I've understood, the problem with default variants is that
if we do something like `port foo -bar` and that foo has
`default_variants +bar`, if an upgrade of foo is released, then `port
upgrade foo` will enable bar variant because variant disabling are
not saved and `default_varia
I'd say installing into /Applications/MacPorts should not be
considered an mtree violation. Check this out:
$ sudo port install minivmac
---> Fetching minivmac
---> Verifying checksum(s) for minivmac
---> Extracting minivmac
---> Configuring minivmac
---> Building minivmac
---> Staging m
I'm not sure I like that mtree violations are fatal errors. The ports
that are now failing to install because of mtree violations installed
just fine in MacPorts 1.5.0. Why should they now fail to install?
Their content has not changed. Sure, they may be installing things in
places they sho
Ryan Schmidt <[EMAIL PROTECTED]> writes:
>I'm not sure I like that mtree violations are fatal errors. The ports
>that are now failing to install because of mtree violations installed
>just fine in MacPorts 1.5.0. Why should they now fail to install?
>Their content has not changed. Sure, they
13 matches
Mail list logo
