Proposal to fix postgresql package maintainance nightmare

[Michelle Sullivan]

Baptiste Daroussin wrote:
> On Tue, Jul 21, 2015 at 01:15:27PM +0200, Michelle Sullivan wrote:
>   
>> Michelle Sullivan wrote:
>>     
>>> That is where your proposal will not work for us that have massive
>>> production infrastructure...without modification... sounds very debianish.
>>>
>>> Here's my thought which follows yours mostly (maybe the same, but not
>>> the way I read yours.)
>>>
>>> All postgres* go under /usr/local/postgresql<major><minor>
>>> rc scripts are always version specific (ie
>>> /usr/local/etc/rc.d/postgresql becomes /usr/local/etc/rc.d/postgresql84,
>>> /usr/local/etc/rc.d/postgresql93 etc)
>>> rc.conf stuff becomes version specific (ie postgresql_enable="YES"
>>> becomes postgresql84_enable="YES" etc)
>>> All ports then can be linked to default versions, the default can be in
>>> Mk/bsd.default-versions.mk, and as it is in /etc/make.conf
>>> All pkg tools then have a dependency to which ever is currently set in
>>> the package and if the required lib is not installed you can install it
>>> without a conflict to what is already on the systems...
>>> All client binaries and tools can have symlinks in /usr/local/bin as
>>> necessary with the major/minor suffix, and the "default versions" of the
>>> *clients and tools* can be symlinked without a major/minor version.
>>>   
>>>       
>> Slight addition...
>>
>> metaport's for 'postgresql-server' and 'postgresql-client' seem to be
>> the ideal addition to this (forget the symlinking and pkgconfig - the
>> metaport would take care of that ideally)
>>
>>     
>
> I do not see the point of having metaport here?
>   

Respectfully, you don't run a massive DB infrastructure.

Metaport would be good for putting in the symlinks to the correct
version you need, would also take care of ensuring pkgconfig has the
right version (not that I compile on the prod servers anymore, but I
know some do)

> We in the end have one single postgresql-client (always latest version)
>   

No - in many cases one would want that, not not all - there were some
differences between 8.4 and 9.0 which were not caught initially (certain
operations (particularly the \<char> commands - which are essentially
hardcoded SQL commands that look at the core schema) in 9.0 didn't work
properly with 8.4 and visa-versa... (if I remember the versions correct
- I'm sure someone here will know for certain which versions) ... on the
other hand the libpq is backwards compatible (so far) for client/server
communications.

> and multiple postgresql*-server which will bundle the client tools they go with
> and the symlinks
>   

here's your issue - I want 8.4 client and 9.4 client on the same host -
how does it know which to symlink, or will both symlink?  A metaport
which looks at the default-version (like python does) would take care of
this with less pain for those that need to test multiple versions on the
same server, or are using their production servers for test (some people
can't afford to keep separate test servers (I can with some 60+ servers
under my wing, but when I started I couldn't - almost everything ran on
the same host when I started with Pg - admittedly this was back in 2002
but even now if I was starting out, even with VMs I probably couldn't
run multiple hosts - as most 'cheap hosting' is now VMs as well and you
can't (usually) run a test VM within your 'cheap host' because it's
already a VM and it is rare to find hosting that will allow VMs within
VMs - if it's even possible.)
>
> so postgresql-client will have
> /usr/local/bin/psql
> and postgresql94-server
> will have:
> /usr/local/bin/psql94 -> /usr/local/postgresql94/bin/psql
>   

This I agree with - however I would suggest postgresql-client is a
metaport as python does rather than a specific python version in case of
future (or past) incompatibility... eg what's going to happen when PG 10
comes out?  A little more work now (possibly less) could save a lot of
re-writing and headaches later.

> For example.
>
> Where would the metaport give something more?
>
> Best regards,
> Bapt
>   


-- 
Michelle Sullivan
http://www.mhix.org/