Naming of postgresql & related
Hi, 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? 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. Could one ask a question from the user and wait for an answer (to confirm the operation)? ! ! Jyrki Wahlstedt ! Kolmas linja 12 A 18 mob. +358-400-347 015 skype:jyrkiwahlstedt ! FI-00530 Helsinki http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386
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. | +========================================================+
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
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."
We've had a couple of longish discussions about how to handle ports with multiple current versions. I think that mysql was the last such debate. Maybe we should have a "policy" about this. I'm thinking something like - one port for each version that the project, itself, deems to be in current service, each with the version number in it (in this case, postgresql74 postgresql80 postgresql81 postgresql82) - one default, empty port which simply has a dependency on the most recent version (in this case, postgresql, which depends on postgresql82). This way, if people do it blindly (postgresql), they get the most recent. If people write ports that need postgresql, they automatically get a dependency on the most recent version. If a writer of another port (say, port "A") discovers that A only works with one specific version of postgresql, they can use one of postgresql{74,81,82} as a dependency. In this case, it would be that port writer's responsibility to update the Portfile for A to the most recent workable dependency (since automatic upgrades have become a non-starter for A). Incidentally, I only think this should be used for specific ports where more than one major version is constantly in active use (apache, mysql, postgresql come to mind). In other cases a "beta" variant might be a better approach. Thoughts? -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University On Sat, 20 Jan 2007, Randall Wood wrote: o I would not remove port:postgresql, but make it an informative port that o installs nothing, instead just spewing out an explanation of the other o postgresql ports. o o I would also replace port:postgresql8 with a port:postgresql80 that carries o the 8.0.x postgresql o and otherwise just keep the other postgresqlx ports current. o o On 20 Jan 2007, at 07:38, Jann Röder wrote: o o > Hi, o > this issue just came to my attention again: On the postgreSQl website o > the following versions are available: o > - 8.2.1 o > - 8.1.6 o > - 8.0.10 o > - 7.4.15 o > o > In macports the following ports are available: o > o > postgresql databases/postgresql 7.4.12 o > postgresql7 databases/postgresql7 7.4.13 o > postgresql8 databases/postgresql8 8.1.3 o > postgresql81 databases/postgresql81 8.1.5 o > postgresql82 databases/postgresql82 8.2.1 o > o > It seems to me that the posgresql8 port is installing the wrong version o > - should be 8.0.10 instead of 8.1.3 , the posgresql port should be o > removed, postgresql7 and psogresql81 are slightly out of date. o > o > So I think the postgresql port (with no version) should be deleted, and o > the others should be updated. o > o > What do you think ? o > o > Jann o > o > Daniel J. Luke wrote: o > > On Nov 4, 2006, at 6:39 AM, Jyrki Wahlstedt wrote: o > > > I just wonder about naming postgresql, some other ports could have the o > > > same. Currently postgresql installs v.7.4.12. Then we have postgresql7 o > > > (v.7.4.13), postgresql8 (v.8.1.3) and postgresql81 (v.8.1.4). This is o > > > a mess. I think postgresql should always be the latest, then we could, o > > > if we want, to have version-specific ports (~7, ~8, ~81). How about o > > > this? o > > o > > This was changed because people do 'port upgrade' and wanted things to o > > work. And because of your point below, the easiest thing is to just have o > > version-specific ports (and let the user handle the file format o > > incompatible upgrades themselves). o > > o > > I believe the 'postgresql' port was deprecated when the decision was o > > made and that it was intended for it to be removed (but I could remember o > > incorrectly). o > > o > > > The related thing comes from the fact that the database formats o > > > between point versions of postgresql are not compatible (8.0->8.1). Is o > > > there a way to make sure that database is dumped before upgrade. o > > o > > That is probably possible, but I don't know if it makes sense to attempt o > > this (for instance, I have a database that would take days to dump that o > > contains data that I'm happy to toss when I want to do an upgrade, but o > > the upgrade step can't know that). o > > o > > Also, 'upgrade' isn't really a normal target, so it would be a hack in o > > the portfile to attempt to do this. o > > o > > > Could one ask a question from the user and wait for an answer (to o > > > confirm the operation)? o > > o > > No. Ports don't prompt for things - this would break unattended o > > (scripted) operation. o > > o > > -- o > > Daniel J. Luke o > > +========================================================+ o > > | *---------------- dluke@geeklair.net o > > ----------------* | o > > | *-------------- http://www.geeklair.net -------------* | o > > +========================================================+ o > > | Opinions expressed are mine and do not necessarily | o > > | reflect the opinions of my employer. | o > > +========================================================+ o > > o > > o > > o > > ------------------------------------------------------------------------ o > > o > > _______________________________________________ o > > macports-dev mailing list o > > macports-dev@lists.macosforge.org o > > http://lists.macosforge.org/mailman/listinfo/macports-dev o > o > _______________________________________________ o > macports-dev mailing list o > macports-dev@lists.macosforge.org o > http://lists.macosforge.org/mailman/listinfo/macports-dev o o o Randall Wood o rhwood@mac.com o o "The rules are simple: The ball is round. The game lasts 90 minutes. All the o rest is just philosophy." o o o _______________________________________________ o macports-dev mailing list o macports-dev@lists.macosforge.org o http://lists.macosforge.org/mailman/listinfo/macports-dev o
On Jan 20, 2007, at 3:27 PM, Salvatore Domenick Desiano wrote:
We've had a couple of longish discussions about how to handle ports with multiple current versions. I think that mysql was the last such debate. Maybe we should have a "policy" about this. I'm thinking something like
- one port for each version that the project, itself, deems to be in current service, each with the version number in it (in this case, postgresql74 postgresql80 postgresql81 postgresql82)
- one default, empty port which simply has a dependency on the most recent version (in this case, postgresql, which depends on postgresql82).
This way, if people do it blindly (postgresql), they get the most recent. If people write ports that need postgresql, they automatically get a dependency on the most recent version. If a writer of another port (say, port "A") discovers that A only works with one specific version of postgresql, they can use one of postgresql{74,81,82} as a dependency. In this case, it would be that port writer's responsibility to update the Portfile for A to the most recent workable dependency (since automatic upgrades have become a non-starter for A).
Incidentally, I only think this should be used for specific ports where more than one major version is constantly in active use (apache, mysql, postgresql come to mind). In other cases a "beta" variant might be a better approach.
Thoughts?
-- Sal smile.
The problem with this is that I remember reading (somewhere) that variants should not change the version! Is that rule to be relaxed in the case of "beta" variants? Peace - John
On 21 Jan 2007, at 20:57, John Ridgway wrote:
On Jan 20, 2007, at 3:27 PM, Salvatore Domenick Desiano wrote:
Incidentally, I only think this should be used for specific ports where more than one major version is constantly in active use (apache, mysql, postgresql come to mind). In other cases a "beta" variant might be a better approach.
The problem with this is that I remember reading (somewhere) that variants should not change the version! Is that rule to be relaxed in the case of "beta" variants?
It is a bad idea for variants to change versions if only because a new version of a port may require different patches, configure arguments, download different source code, etc, and lead to a massive, unwieldily, and most-likely difficult to read portfile. In addition, the port index will not be able to accurately reflect the port version or dependencies if that happens. Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
Hi, I have 8.0.10 portfiles ready. I assume it is ok to commit that as postgresql80?! Committing that as postgresql8 would be weird, because the version would change from 8.1.3 to 8.0.10 causing difficulties with binary format. On 20.1.2007, at 16.35, Randall Wood wrote:
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. | +========================================================+
Randall Wood rhwood@mac.com
"The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
! ! Jyrki Wahlstedt ! skype:jyrkiwahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386
participants (6)
-
Daniel J. Luke
-
Jann Röder
-
John Ridgway
-
Jyrki Wahlstedt
-
Randall Wood
-
Salvatore Domenick Desiano