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)
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev