Naming of postgresql & related

[Randall Wood]

On 20 Jan 2007, at 13:57, Matthew Ross wrote:

> While we are on the postgresql port topic... Why are there  
> postgresql8*-server and postgresql8*-doc ports?  Shouldn't these be  
> variants of the postgresql8* port?  Isn't this the purpose of  
> variants?

It is the purpose of variants, and in this case it seems very silly  
not to simply install the docs in the postgresql8* port since we  
downloaded them there anyway, but the *-server port seems  
interesting. It depends entirely upon the postgresql8* port , but  
adds a startup item to the system.

There is one problem in relying on variants, and it is that a  
dependency on a specific variant can not be listed in a port (you can  
find discussions in the archives), so making a *-server port serves a  
purpose in that I can depend on the server being setup, whereas if I  
could only specify the server in a variant, a depending port could  
not rely on it being installed correctly.

Since startup items are not automatically enabled (at least in Mac OS  
X 10.4+), I don't see why all three ports postgresql8*, postgresql8*- 
doc, and postgresql8*-server can not be done in a single ports, with  
variants to disable the installation of the docs or startup item.

> On Jan 20, 2007, at 8:35 AM, 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 at 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 at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo/macports-dev
>>>
>>> _______________________________________________
>>> macports-dev mailing list
>>> macports-dev at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo/macports-dev
>>
>>
>> Randall Wood
>> rhwood at mac.com
>>
>> "The rules are simple: The ball is round. The game lasts 90  
>> minutes. All the
>> rest is just philosophy."
>>
>>
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo/macports-dev
>


Randall Wood
rhwood at mac.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."