Re: *-devel ports

[Thomas de Grivel]

2008/2/7, Ryan Schmidt <[EMAIL PROTECTED]>:
>
> On Feb 7, 2008, at 09:10, Vincent Lefevre wrote:
>
> > On 2008-02-07 15:21:41 +0100, Thomas de Grivel wrote:
> >
> >> 2008/2/7, Ryan Schmidt:
> >>
> >>> It was proposed that -devel ports should be updated to the latest
> >>> stable version, if the latest stable version is newer than the
> >>> latest
> >>> development version. If we act on this proposal, then "-latest" is
> >>> more intuitive than "-devel".
> >>
> >> Ok I see the point. In other terms it is a pointer to a stable or
> >> -devel  version of the same port, like a virtual package depending on
> >> the right one ?
> >
> > Yes, more or less.
>
> Actually no, I was not intending for there to be any virtual packages.
>
> Let's do an example. The way it is now, "mysql5" is the latest
> released version of MySQL (5.0.51) and "mysql5-devel" is the latest
> development version (5.1.22-rc). Let us now assume for the sake of
> this example that the next version of MySQL that is released is
> 5.1.25 and it is considered a released version. To follow our current
> practices, "mysql5" will be updated to 5.1.25 and "mysql5-devel" will
> not be updated and will remain at 5.1.22-rc, until a development
> version of MySQL 5.2 is released. Or maybe it will switch to version
> 6.0 at that point.
>
> The proposal is that when the hypothetical stable version 5.1.25 is
> released, "mysql5" will be updated to 5.1.25, and "mysql5-devel" will
> also be updated to 5.1.25. Both ports will then be identical until
> the next development release.

Put this way indeed it really sounds right. Sorry if I misunderstood
the other explanations.

--
  Thomas de Grivel
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [33938] trunk/base/src/macports1.0/macports.tcl

[Rainer Müller]

Ryan Schmidt wrote:

What is being prepended to what? Or did you mean "pretend"?


Ouch. Of course I meant that! Somehow I got it wrong and didn't notice 
it at all. Sorry...

Thanks, I am going to fix this.

Rainer


___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [33938] trunk/base/src/macports1.0/macports.tcl

[Ryan Schmidt]

On Feb 7, 2008, at 21:34, [EMAIL PROTECTED] wrote:


Revision: 33938
  http://trac.macosforge.org/projects/macports/changeset/33938
Author:   [EMAIL PROTECTED]
Date: 2008-02-07 19:34:55 -0800 (Thu, 07 Feb 2008)

Log Message:
---
macports1.0/macports.tcl:
Add --prepend option to selfupdate, which will check if an update  
is necessary.

I had to rearrange some things in order to present nice output.


What is being prepended to what? Or did you mean "pretend"?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac and Subversion down?

[Ryan Schmidt]

Super, thanks! It seems to be back up for now.

On Feb 7, 2008, at 20:44, William Siegrist wrote:

Sorry, emergency maintenance. Its all back now, let me know if you  
still have trouble. The short notice was due to the general  
slowness you mentioned.  I'll be doing some more stuff over the  
next few days too to try and help.


On Feb 7, 2008, at 6:20 PM, Ryan Schmidt wrote:

Trac has been very slow lately, but right now it's not responding  
at all:


The operation timed out when attempting to contact  
trac.macosforge.org.
The requested site did not respond to a connection request and  
Camino has stopped waiting for a reply.


and neither is Subversion:

gnucash $ svn log
svn: PROPFIND request failed on '/repository/macports/trunk/dports/ 
gnome/gnucash'
svn: PROPFIND of '/repository/macports/trunk/dports/gnome/ 
gnucash': could not connect to server (http://svn.macosforge.org)

gnucash $

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac and Subversion down?

[William Siegrist]

Sorry, emergency maintenance. Its all back now, let me know if you  
still have trouble. The short notice was due to the general slowness  
you mentioned.  I'll be doing some more stuff over the next few days  
too to try and help.


-Bill


On Feb 7, 2008, at 6:20 PM, Ryan Schmidt wrote:
Trac has been very slow lately, but right now it's not responding at  
all:


The operation timed out when attempting to contact  
trac.macosforge.org.
The requested site did not respond to a connection request and  
Camino has stopped waiting for a reply.


and neither is Subversion:

gnucash $ svn log
svn: PROPFIND request failed on '/repository/macports/trunk/dports/ 
gnome/gnucash'
svn: PROPFIND of '/repository/macports/trunk/dports/gnome/gnucash':  
could not connect to server (http://svn.macosforge.org)

gnucash $








William Siegrist
Software Support Engineer
Mac OS Forge
http://macosforge.org/
[EMAIL PROTECTED]
408 862 7337







smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Trac and Subversion down?

[Ryan Schmidt]

Trac has been very slow lately, but right now it's not responding at  
all:


The operation timed out when attempting to contact trac.macosforge.org.
The requested site did not respond to a connection request and Camino  
has stopped waiting for a reply.


and neither is Subversion:

gnucash $ svn log
svn: PROPFIND request failed on '/repository/macports/trunk/dports/ 
gnome/gnucash'
svn: PROPFIND of '/repository/macports/trunk/dports/gnome/gnucash':  
could not connect to server (http://svn.macosforge.org)

gnucash $


___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: universal flags and configuration

[Rainer Müller]

Ryan Schmidt wrote:

There are some workarounds for known shortcomings/bugs, such as
setting -mmacosx-version-min instead of macosx_deployment_target
when the variable don't want to take effect,


The documentation I've read says to use MACOSX_DEPLOYMENT_TARGET 
environment variable. When is this -mmacosx-version-min applicable instead?


As far as I know, it is possible to either use MACOSX_DEPLOYMENT_TARGET 
as env var or directly pass -mmacosx-version-min to gcc. But the latter 
takes preference over the former.


Rainer


___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: universal flags and configuration

[Ryan Schmidt]

On Feb 7, 2008, at 03:30, Anders F Björklund wrote:


I've added some configure. flags for +universal variants,
and also to the macports.conf file for providing defaults.

They are:

- universal_target
  # for setting macosx_deployment_target and configure target
  Default: 10.4

- universal_sysroot
  # the SDK "sysroot" to use, normally for the -isysroot flag
  Default: /Developer/SDKs/MacOSX10.4u.sdk

- universal_archs
  # machine architectures to use, can be more than just one
  Default: ppc i386


There are some workarounds for known shortcomings/bugs, such as
setting -mmacosx-version-min instead of macosx_deployment_target
when the variable don't want to take effect,


The documentation I've read says to use MACOSX_DEPLOYMENT_TARGET  
environment variable. When is this -mmacosx-version-min applicable  
instead?



or adding -syslibroot
on PowerPC so that it doesn't forget to use the Intel versions...


Apple documentation on building universal binaries from configure- 
based software used to mention -syslibroot but this was removed quite  
some time ago. When is it still applicable?



The additions means that it will now cross-compile when necessary,


As I understand it, cross-compiling is compiling for a platform other  
than the one on which the compiler is running. Haven't we already  
been doing that when building universal binaries?



and that +universal target is meant to generate similar binaries*.
By changing the values, it's possible to build for the Leopard SDK
and even the Panther SDK (cross-compiling to a previous OS version)

Currently these do _not_ affect the MacPorts os. variables, though.
These use the currently running operating system, and nothing else
(i.e. they aren't affected by changing these universal variables)
So it would still say "+darwin_9" and "+i386", even for Panther SDK.

However, if you do set the universal_target to a certain version
then it will pass matching configure flags to autoconf/automake.
For instance, when using the default MacOSX10.4u.sdk, it'll use:
configure --host=i686-apple-darwin8 --target=i686-apple-darwin8



What problem does setting --host and --target solve? Because for me  
it's causing a problem, namely that glib2 doesn't build universal  
anymore. I traced this failure back to r33483 in which you added the  
--host and --target switches. With trunk r33482 (without those  
switches), glib2 builds universal. With trunk r33483 (with them), it  
does not.


Possibly suspicious output from glib2's ./configure at the beginning:

configure: WARNING: If you wanted to set the --build type, don't use  
--host.
If a cross compiler is detected then cross compile mode will be  
used.


Definitely suspicious output from glib2's ./configure:

checking whether to use assembler code for atomic operations... i486

With r33482 it says:

checking whether to use assembler code for atomic operations... none

Definitely suspicious output from glib2's make at the end:

 /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -DG_LOG_DOMAIN= 
\"GLib\" -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED - 
DGLIB_COMPILATION -DPCRE_STATIC -I/opt/local/include -isysroot / 
Developer/SDKs/MacOSX10.4u.sdk -D_REENTRANT -O2 -funroll-loops - 
fstrict-aliasing -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc - 
arch i386 -Wall -c gatomic.c  -fno-common -DPIC -o .libs/gatomic.o

gatomic.c: In function 'g_atomic_int_compare_and_exchange':
gatomic.c:66: error: impossible constraint in 'asm'
lipo: can't figure out the architecture type of: /var/tmp//ccmwc7KI.out
make[4]: *** [gatomic.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[Ryan Schmidt]

On Feb 7, 2008, at 07:08, js wrote:


On Feb 7, 2008 1:58 PM, Ryan Schmidt wrote:


I think -devel is better.
For one thing, it's more intuitive.


It was proposed that -devel ports should be updated to the latest
stable version, if the latest stable version is newer than the latest
development version. If we act on this proposal, then "-latest" is
more intuitive than "-devel".


I agree with you,
but I think that the situation that devel-ver < stable-ver is very  
rare.
I've never seen it. (By newer, you means the version number is  
greater, right?)


Then let me acquaint you with our ports tree:

boehmgc (7.0) is newer than boehmgc-devel (6.3alpha6)
php5 (5.2.5) is newer than php5-devel (5.2.5RC2)
swi-prolog (5.6.50) is newer than swi-prolog-devel (5.5.36)
sylpheed (2.2.3) is newer than sylpheed-devel (2.2.0beta7)
tin (1.8.3) is newer than tin-devel (1.7.10)
wxWidgets (2.8.7) is newer than wxWidgets-devel (2.8.6-rc1)
yap (5.0.1) is newer than yap-devel (4.5.6)
zeroinstall-injector (0.31) is newer than zeroinstall-injector-devel  
(0.30)


Some ports are already updating the -devel port to the same version  
as the regular port:


Etoile (0.1.9) and Etoile-devel (0.1.9)
mpd (0.13.1) and mpd-devel (0.13.1)

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[Ryan Schmidt]

On Feb 7, 2008, at 09:10, Vincent Lefevre wrote:


On 2008-02-07 15:21:41 +0100, Thomas de Grivel wrote:


2008/2/7, Ryan Schmidt:


It was proposed that -devel ports should be updated to the latest
stable version, if the latest stable version is newer than the  
latest

development version. If we act on this proposal, then "-latest" is
more intuitive than "-devel".


Ok I see the point. In other terms it is a pointer to a stable or
-devel  version of the same port, like a virtual package depending on
the right one ?


Yes, more or less.


Actually no, I was not intending for there to be any virtual packages.

Let's do an example. The way it is now, "mysql5" is the latest  
released version of MySQL (5.0.51) and "mysql5-devel" is the latest  
development version (5.1.22-rc). Let us now assume for the sake of  
this example that the next version of MySQL that is released is  
5.1.25 and it is considered a released version. To follow our current  
practices, "mysql5" will be updated to 5.1.25 and "mysql5-devel" will  
not be updated and will remain at 5.1.22-rc, until a development  
version of MySQL 5.2 is released. Or maybe it will switch to version  
6.0 at that point.


The proposal is that when the hypothetical stable version 5.1.25 is  
released, "mysql5" will be updated to 5.1.25, and "mysql5-devel" will  
also be updated to 5.1.25. Both ports will then be identical until  
the next development release.



___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[Vincent Lefevre]

On 2008-02-07 09:47:45 -0500, Daniel J. Luke wrote:
> On Feb 7, 2008, at 9:03 AM, Emmanuel Hainry wrote:
>> Seeing that there are 5 different postgresql port (7,
>> 80, 81, 82, 83) makes me quite puzzled, which one is considered  
>> stable?
>
> Each postgres version in macports has an on-disk format that is  
> incompatible with the next (newer) release.

BTW, there's a similar problem with unison. Should I commit my
unison-2.13 port[*] (based on the old unison port)? (I'm not sure
the port name follows the right convention if there's one.)

[*] http://trac.macosforge.org/projects/macports/ticket/14172

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[Vincent Lefevre]

On 2008-02-07 15:21:41 +0100, Thomas de Grivel wrote:
> 2008/2/7, Ryan Schmidt <[EMAIL PROTECTED]>:
> >It was proposed that -devel ports should be updated to the latest
> >stable version, if the latest stable version is newer than the latest
> >development version. If we act on this proposal, then "-latest" is
> >more intuitive than "-devel".
> 
> Ok I see the point. In other terms it is a pointer to a stable or
> -devel  version of the same port, like a virtual package depending on
> the right one ?

Yes, more or less.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[Vincent Lefevre]

On 2008-02-07 23:00:14 +0900, js wrote:
> If the developer call it as stable and the other's development,
> Let' follow it.
> Anyone who like to use newer can easily choose -devel one.

However this may be confusing for the end user, as depending on the
developers, "unstable" doesn't always mean the same thing. For some
of them, it means untested / probably buggy; for others it means
changing, but not necessarily more buggy than stable releases (and
sometimes even known to be less buggy).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[Daniel J. Luke]

On Feb 7, 2008, at 9:03 AM, Emmanuel Hainry wrote:

Seeing that there are 5 different postgresql port (7,
80, 81, 82, 83) makes me quite puzzled, which one is considered  
stable?


Each postgres version in macports has an on-disk format that is  
incompatible with the next (newer) release.


Since macports tries to have only the 'stable' (release) versions of  
software (unless they're clearly marked as otherwise) the newest one  
is probably what you want.


Postgres has to do this as if there was just a postgres port and a  
user upgraded from say postgres7 to postgres8, they would be unable to  
use their existing database and since they probably uninstalled the  
old postgres when upgrading to the new one, also unable to easily  
recover.


(our upgrade process starting out as a clever hack that would just  
uninstall the old software and install the new software, doesn't  
provide hooks to let the portfile author attempt to automatically  
convert from the old postgres to the new one)


--
Daniel J. Luke
++
| * [EMAIL PROTECTED] * |
| *-- http://www.geeklair.net -* |
++
|   Opinions expressed are mine and do not necessarily   |
|  reflect the opinions of my employer.  |
++





PGP.sig
Description: This is a digitally signed message part
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[Thomas de Grivel]

2008/2/7, js <[EMAIL PROTECTED]>:
> If the developer call it as stable and the other's development,
> Let' follow it.
> Anyone who like to use newer can easily choose -devel one.

I think we all agree on this (we dont have time to test stability, ffs).

2008/2/7, Ryan Schmidt <[EMAIL PROTECTED]>:
>It was proposed that -devel ports should be updated to the latest
>stable version, if the latest stable version is newer than the latest
>development version. If we act on this proposal, then "-latest" is
>more intuitive than "-devel".

Ok I see the point. In other terms it is a pointer to a stable or
-devel  version of the same port, like a virtual package depending on
the right one ?

I also cannot avoid comparing with Gentoo : they use multiple 'ebuild'
files (the converse of a portfile) to reflect the different versions
of a package. That done they can mark each version as stable/unstable
and allow to install different versions when they have different
'slots' (like for gtk-1 and gtk-2 : they consider it is the same
"port" but with a different slot so both can be installed). I dont
suggest to rip it off them but that is another existing solution to
this problem. Well multiple versions is another larger issue I don't
mean to bring here.

--
  Thomas de Grivel
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[js]

Naming convention in Debian/GNU Linux solves your problem.
Take python for example.
They provides a meta package named "python", which requires
the stable python (2.4 or 2.5?). That's nice.
However, I think achieving it in MacPorts would be quite  difficult...

On Feb 7, 2008 11:03 PM, Emmanuel Hainry <[EMAIL PROTECTED]> wrote:
> Citando js :
>
> > On Feb 7, 2008 1:58 PM, Ryan Schmidt <[EMAIL PROTECTED]> wrote:
> > > >> I think -devel is better.
> > > >> For one thing, it's more intuitive.
> > >
> > > It was proposed that -devel ports should be updated to the latest
> > > stable version, if the latest stable version is newer than the latest
> > > development version. If we act on this proposal, then "-latest" is
> > > more intuitive than "-devel".
> >
> > I agree with you,
> > but I think that the situation that devel-ver < stable-ver is very rare.
> > I've never seen it. (By newer, you means the version number is greater, 
> > right?)
> > So I don't agree with that proposal.
> > -devel = development is more frequently used
> > so, at least for me, -devel is more natural and intuitive.
> >
> > Actually, I prefer simple name like
> > mysql51 or python30 instead of mysql5-devel or python30-devel, but I
> > found this naming convension is not popular ;)
>
> The problem with such names is that to decide which port to install you
> have to search the project website to know which version is the most
> suitable for you. Seeing that there are 5 different postgresql port (7,
> 80, 81, 82, 83) makes me quite puzzled, which one is considered stable?
> Is the oldest deprecated and only there for backwards compatibility or
> is it the stable version and all 8x are more or less cutting edge and
> presumably broken. Is there an even is unstable, odd is stable
> convention?
>
> The irssi, irssi-devel case on the other hand is quite clear, if you
> want stable, go for irssi, if you need latest features, go for -devel.
>
> zsh and mutt are however bad examples as the considered stable version
> is too old lacks many features (and probably security).
>
> I therefore prefer the -devel naming, but would like to have some not
> tagged stable but proved enough ports to become the stable version (it
> is up to the maintainer to decide if it should be upgraded or not in the
> end).
>
> Emmanuel
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[Emmanuel Hainry]

Citando js :
> On Feb 7, 2008 1:58 PM, Ryan Schmidt <[EMAIL PROTECTED]> wrote:
> > >> I think -devel is better.
> > >> For one thing, it's more intuitive.
> >
> > It was proposed that -devel ports should be updated to the latest
> > stable version, if the latest stable version is newer than the latest
> > development version. If we act on this proposal, then "-latest" is
> > more intuitive than "-devel".
> 
> I agree with you,
> but I think that the situation that devel-ver < stable-ver is very rare.
> I've never seen it. (By newer, you means the version number is greater, 
> right?)
> So I don't agree with that proposal.
> -devel = development is more frequently used
> so, at least for me, -devel is more natural and intuitive.
> 
> Actually, I prefer simple name like
> mysql51 or python30 instead of mysql5-devel or python30-devel, but I
> found this naming convension is not popular ;)

The problem with such names is that to decide which port to install you
have to search the project website to know which version is the most
suitable for you. Seeing that there are 5 different postgresql port (7,
80, 81, 82, 83) makes me quite puzzled, which one is considered stable?
Is the oldest deprecated and only there for backwards compatibility or
is it the stable version and all 8x are more or less cutting edge and
presumably broken. Is there an even is unstable, odd is stable
convention?

The irssi, irssi-devel case on the other hand is quite clear, if you
want stable, go for irssi, if you need latest features, go for -devel.

zsh and mutt are however bad examples as the considered stable version
is too old lacks many features (and probably security).

I therefore prefer the -devel naming, but would like to have some not
tagged stable but proved enough ports to become the stable version (it
is up to the maintainer to decide if it should be upgraded or not in the
end). 

Emmanuel
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[js]

If the developer call it as stable and the other's development,
Let' follow it.
Anyone who like to use newer can easily choose -devel one.

On Feb 7, 2008 10:50 PM, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> On 2008-02-07 22:08:57 +0900, js wrote:
> > I agree with you,
> > but I think that the situation that devel-ver < stable-ver is very
> > rare. I've never seen it. (By newer, you means the version number is
> > greater, right?)
>
> It happens for tin almost each time a new stable version is released
> (because it is released before new development work starts). The same
> thing seems to happen with zsh:
>
>   http://zsh.dotsrc.org/News/
>
> 4.2.0 (stable) was released on 2004-03-19, a 4.3 (unstable) series was
> announced on 2005-02-08, and the first 4.3-based version (4.3.1) was
> released on 2006-02-28. So, for almost two years, the latest version
> (in term of features and bug fixes) was a stable release!
>
> --
> Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
> ___
>
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[Vincent Lefevre]

On 2008-02-07 14:50:03 +0100, Vincent Lefevre wrote:
> It happens for tin almost each time a new stable version is released
> (because it is released before new development work starts). [...]

Here I meant a new stable branch (not just a bug-fix stable version),
i.e. a new version of the form x.y.0 with y even.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[Vincent Lefevre]

On 2008-02-07 22:08:57 +0900, js wrote:
> I agree with you,
> but I think that the situation that devel-ver < stable-ver is very
> rare. I've never seen it. (By newer, you means the version number is
> greater, right?)

It happens for tin almost each time a new stable version is released
(because it is released before new development work starts). The same
thing seems to happen with zsh:

  http://zsh.dotsrc.org/News/

4.2.0 (stable) was released on 2004-03-19, a 4.3 (unstable) series was
announced on 2005-02-08, and the first 4.3-based version (4.3.1) was
released on 2006-02-28. So, for almost two years, the latest version
(in term of features and bug fixes) was a stable release!

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[js]

> > Some of our non-devel ports do install development versions because
> > the latest releases don't work at all or are years out of date, say.
> > But generally this should not be the case. If you think the latest
> > stable release of a program is not suitable, then you should push
> > the developers to make a new release that is.
>
> I don't think that MacPorts users have enough power.

Out of date ports means  no one uses it.
If someone really want it, he/she'll do something about it.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[Vincent Lefevre]

On 2008-02-06 22:58:56 -0600, Ryan Schmidt wrote:
> It's not really the place of a MacPorts port maintainer to second-guess 
> the developer of the software regarding what version is stable enough for 
> a user to use.

The following may be useful to decide:
  * read the development mailing-list;
  * see what other distributions do;
  * look at the date of the latest stable release.

For instance, Debian/stable has:
  * mutt 1.5.13 (the 1.4 stable version was released in May 2002, and
there have been a few security fixes since, and I don't even think
that all security fixes have been applied to 1.4).
  * zsh 4.3.2 (the 4.2.0 stable version was released in March 2004,
with a few bug fixes since, but no UTF-8 support, while this would
be quite important, in particular under Mac OS X, as HFS+ stores
filenames in UTF-8).

Note that even though Debian distributes a development version of zsh,
it also has zsh-beta, which more or less corresponds to the HEAD (and
can be installed in parallel).

> Some of our non-devel ports do install development versions because
> the latest releases don't work at all or are years out of date, say.
> But generally this should not be the case. If you think the latest
> stable release of a program is not suitable, then you should push
> the developers to make a new release that is.

I don't think that MacPorts users have enough power.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: *-devel ports

[js]

On Feb 7, 2008 1:58 PM, Ryan Schmidt <[EMAIL PROTECTED]> wrote:
> >> I think -devel is better.
> >> For one thing, it's more intuitive.
>
> It was proposed that -devel ports should be updated to the latest
> stable version, if the latest stable version is newer than the latest
> development version. If we act on this proposal, then "-latest" is
> more intuitive than "-devel".

I agree with you,
but I think that the situation that devel-ver < stable-ver is very rare.
I've never seen it. (By newer, you means the version number is greater, right?)
So I don't agree with that proposal.
-devel = development is more frequently used
so, at least for me, -devel is more natural and intuitive.

Actually, I prefer simple name like
mysql51 or python30 instead of mysql5-devel or python30-devel,
but I found this naming convension is not popular ;)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

universal flags and configuration

[Anders F Björklund]

I've added some configure. flags for +universal variants,
and also to the macports.conf file for providing defaults.

They are:

- universal_target
  # for setting macosx_deployment_target and configure target
  Default: 10.4

- universal_sysroot
  # the SDK "sysroot" to use, normally for the -isysroot flag
  Default: /Developer/SDKs/MacOSX10.4u.sdk

- universal_archs
  # machine architectures to use, can be more than just one
  Default: ppc i386


There are some workarounds for known shortcomings/bugs, such as
setting -mmacosx-version-min instead of macosx_deployment_target
when the variable don't want to take effect, or adding -syslibroot
on PowerPC so that it doesn't forget to use the Intel versions...

The additions means that it will now cross-compile when necessary,
and that +universal target is meant to generate similar binaries*.
By changing the values, it's possible to build for the Leopard SDK
and even the Panther SDK (cross-compiling to a previous OS version)

Currently these do _not_ affect the MacPorts os. variables, though.
These use the currently running operating system, and nothing else
(i.e. they aren't affected by changing these universal variables)
So it would still say "+darwin_9" and "+i386", even for Panther SDK.

However, if you do set the universal_target to a certain version
then it will pass matching configure flags to autoconf/automake.
For instance, when using the default MacOSX10.4u.sdk, it'll use:
configure --host=i686-apple-darwin8 --target=i686-apple-darwin8


It still only works for ports using configure and not hardcoding
architecture into generated files (like endianness for instance),
and there still needs to be an implementation that will build
twice (once for each arch) and then merge the results together.

Also left to do is to wire the above settings into Xcode group,
by using appropriate parameters to the xcodebuild(1) command...
(variables like SYSROOT and ARCHS should be straightforward,
and I think the remaining one is MACOSX_DEPLOYMENT_TARGET ?)

Thoughts?
--anders

* this default is a change from MacPorts 1.6.0, that used 10.5 SDK
  on Leopard and 10.4u SDK on Tiger (but is the same as in 1.5/1.4)


___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev