upgrade outdated conflicts

[Tom Allison]

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.
>