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
+========================================================+
| *---------------- [EMAIL PROTECTED]
----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+
---------------------------------------------------------------------
---
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood
[EMAIL PROTECTED]
"The rules are simple: The ball is round. The game lasts 90 minutes.
All the
rest is just philosophy."
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
