Naming of postgresql & related

[Salvatore Domenick Desiano]

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 at 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 at lists.macosforge.org
o > > http://lists.macosforge.org/mailman/listinfo/macports-dev
o > 
o > _______________________________________________
o > macports-dev mailing list
o > macports-dev at lists.macosforge.org
o > http://lists.macosforge.org/mailman/listinfo/macports-dev
o 
o 
o Randall Wood
o rhwood at 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 at lists.macosforge.org
o http://lists.macosforge.org/mailman/listinfo/macports-dev
o