1.6.0 rc2 created (Was Re: [31193] branches/release_1_6/base/src)

[Anders F Björklund]

Juan Manuel Palacios wrote:

>> Nah, myself I just thought the available pkg information should be 
>> better.
>
> 	I'm sorry, I didn't follow that comment. Mind elaborating?

As long as the download links explains which version of DMG / PKG to get
for which version of Mac OS X, most users will able to pick the right 
one.

> 	In any case, can you please take a look at what Ryan Maun Suang and I 
> discussed on that ticket? A  *.pkg/Contents/Resources/VolumeCheck 
> script parsing the output of sw_vers(1) might do the trick for us, but 
> you've been working on the pkg targets lately so you're probably much 
> more fit than any of us to tell how we could achieve our goal on 
> Tiger/Leopard with traditional/flat pkg formats. Pretty please....? 
> ;-)

The flat meta-packages seem to be broken with Xcode 3.0.0, so I wouldn't
worry about it. Checking sw_vers in the script, probably works. I think
there might be a built-in way to do it, but it's different for each OS.
(i.e. one way for 10.3, one way for 10.4, one way for 10.5 - as 
usual...)

> 	OK, will definitely try to fix it for that scenario. However, my 
> recommendation still stands: avoid paths with spaces in them if 
> possible!

No argument there... Goes for you too, Apple! "Application Support", 
sheesh.

>> The current RPM ports should be more than enough to sort out the 
>> other problems that MacPorts has with binary package (rpm) building - 
>> at the moment it looks like doing binary archives (tlz) would be a 
>> better alternative ?
>
> 	First comes building logging support into MacPorts (my nex goal & top 
> priority after the new website and 1.6) and then constructing our 
> automated & distributed builds infrastructure (build farms, chroots, 
> trace mode, etc) to actually have something to package, so I wouldn't 
> worry too much just yet about fleshing out rpm issues in MacPorts at 
> the moment. I more than love the effort and work you're putting into 
> packaging and how you're pushing us forward on this front, trust me 
> (!!); but, sadly, whatever packaging effort we put together is going 
> to be pretty lousy without support for automated builds & logging.

In order for the packages to be more useful, everything should be using 
them.

So that you can mix and match binary packages and source packages 
freely...
Like how Fink does it ? When you install a "port", it first builds a 
package
and then installs the package. Thus, it knows about all the other 
"ports" too.
In MacPorts, each package system (PKG/RPM/DEB) is separated from port 
registry.

You can still do binaries, of course, just that it seems more likely 
that they
would just be archives of destroot (tgz/tbz/tlz) instead of "real" 
packages ?
The important things to me are a) installing ports *without* Developer 
Tools
and b) remote download of pre-built binary packages and all their 
dependencies

http://trac.macports.org/projects/macports/ticket/8571
(also involves fixing "upgrade" so it actually works)

--anders

PS. On an unrelated note, MacPorts 1.6.0RC2 installed OK on the Darwin 
8.0.1 OS
once the bogus dependencies on Foundation were hacked out 
(configure/tclobjc1.0)
On the other two platforms I installed GNUstep instead, but there was 
no easy way
of doing that on Darwin (but I guess I could have used DarwinPorts to 
bootstrap)