I'm not certain about the incompatibility of postgres versions. It is a
case by case issue, but generally the practice is to
dump/upgrade/restore if there is any doubt. For my development box,
it's not an issue.
As for perl -- can you specific a minimum version requirement (>= 5.8)
instead of tagging it to a version. This is something I've seen in
Debian, but I'm not familiar with the details of how they do it.
Ryan Schmidt wrote:
On Apr 6, 2008, at 05:42, Tom Allison wrote:
I'm struggling with the upgrade process right now.
I've completed the following:
selfupdate
upgrade outdated
But now I have soem mixed packages like:
postgresql81
postgresql82
postgresql83
in addition to postgres 8.2 having three versions itself.
There are mayby 50+ of these right now.
port -u upgrade outdated never completed successfully because of
dependencies.
Question: I would like to remove as many of these old versions as I
can but it seems that getting all the dependencies out of the way is
going to take a while for all the packages to be updated by the
maintainer. If I wait and just keep running '-u update outdated' will
I eventually clean up all the old packages?
Yeah, "port -u upgrade outdated" isn't a great command, it seems. See my
other reply to you a moment ago about a better set of commands.
And can someone make any suggestion on what to do with the version
conflicts like perl5.8/perl5.10 and postgresql81..83. I eventually
would like to migrate everything to a common package like perl 5.10
but I guess right now I really can't do that because of things like
p5-dbd-pg still being tied back to 5.10...
Will package upgrades like perl5.8 eventually upgrade themselves to
perl5.10 once all the package dependencies are also upgrade?
I do not know what our plan is with regard to perl5.8/perl5.10. Ideally,
each port that depends on perl would declare the dependency in such a
way that either port would satisfy the dependency. That is, instead of
writing "depends_lib port:perl5.8", ports could write "depends_lib
path:${prefix}/bin/perl:perl5.8"; that way, if a perl is already
installed (by either perl5.8 or perl5.10), then the dependency is
satisfied, otherwise perl5.8 is installed. But at this time, it looks
like we have about 86 ports that depend on "port:perl5.8", 2 that depend
on "port:perl5.10", and 6 that use the "path:" syntax.
As for postgresql, I understand that each major version is incompatible
with the last. That is, a database that works with 8.1 does not work
with 8.2 until you manually upgrade it, at which point it doesn't work
with 8.1 anymore. Therefore, separate ports, to give users the choice of
when to upgrade to newer versions. If you find ports that depend only on
a specific version of postgresql, and do not give you variants to let
you choose which version you would like to use, please file enhancement
request tickets against those ports.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
