I would not remove port:postgresql, but make it an informative port that installs nothing, instead just spewing out an explanation of the other postgresql ports. I would also replace port:postgresql8 with a port:postgresql80 that carries the 8.0.x postgresql and otherwise just keep the other postgresqlx ports current. On 20 Jan 2007, at 07:38, Jann Röder wrote:
Hi, this issue just came to my attention again: On the postgreSQl website the following versions are available: - 8.2.1 - 8.1.6 - 8.0.10 - 7.4.15
In macports the following ports are available:
postgresql databases/postgresql 7.4.12 postgresql7 databases/postgresql7 7.4.13 postgresql8 databases/postgresql8 8.1.3 postgresql81 databases/postgresql81 8.1.5 postgresql82 databases/postgresql82 8.2.1
It seems to me that the posgresql8 port is installing the wrong version - should be 8.0.10 instead of 8.1.3 , the posgresql port should be removed, postgresql7 and psogresql81 are slightly out of date.
So I think the postgresql port (with no version) should be deleted, and the others should be updated.
What do you think ?
Jann
Daniel J. Luke wrote:
On Nov 4, 2006, at 6:39 AM, Jyrki Wahlstedt wrote:
I just wonder about naming postgresql, some other ports could have the same. Currently postgresql installs v.7.4.12. Then we have postgresql7 (v.7.4.13), postgresql8 (v.8.1.3) and postgresql81 (v.8.1.4). This is a mess. I think postgresql should always be the latest, then we could, if we want, to have version-specific ports (~7, ~8, ~81). How about this?
This was changed because people do 'port upgrade' and wanted things to work. And because of your point below, the easiest thing is to just have version-specific ports (and let the user handle the file format incompatible upgrades themselves).
I believe the 'postgresql' port was deprecated when the decision was made and that it was intended for it to be removed (but I could remember incorrectly).
The related thing comes from the fact that the database formats between point versions of postgresql are not compatible (8.0-
8.1). Is there a way to make sure that database is dumped before upgrade.
That is probably possible, but I don't know if it makes sense to attempt this (for instance, I have a database that would take days to dump that contains data that I'm happy to toss when I want to do an upgrade, but the upgrade step can't know that).
Also, 'upgrade' isn't really a normal target, so it would be a hack in the portfile to attempt to do this.
Could one ask a question from the user and wait for an answer (to confirm the operation)?
No. Ports don't prompt for things - this would break unattended (scripted) operation.
-- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
--------------------------------------------------------------------- ---
_______________________________________________ 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
Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."