Opened 10 years ago

Closed 8 years ago

#20810 closed request (fixed)

postgresql_select port request

Reported by: apinstein@… Owned by: mww@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: jyrkiwahlstedt, ryandesign (Ryan Schmidt)
Port: postgresql_select

Description (last modified by ryandesign (Ryan Schmidt))

configure.args  --sysconfdir=${prefix}/etc/${name} \
                --bindir=${libdir}/bin \

After install the pgsql executables are all in /opt/local/lib/postgresql83/bin/psql instead of /opt/local/bin. This is pretty annoying since I have to add the pg-specific bin dir to my path.

Why aren't these droppped into bin/? Is there a name conflict with executables from other ports? Do you want to preserve the ability to run multiple pg's side-by-side?

I would be OK with that decision but at least you should provide a variant to directly install the executables into the bin dir.

Change History (12)

comment:1 Changed 10 years ago by blb@…

Cc: jwa@… added
Owner: changed from macports-tickets@… to mww@…
Port: postgresql83 added

Yes, the idea is to make sure you can have, say, postgresql83 and postgresql84 installed simultaneously (eg, if you are upgrading, you'll need to dump from 8.3 then import to 8.4, so easiest is to have them both available).

Leaving for mww/jwa whether a variant makes sense...

comment:2 Changed 9 years ago by jmroot (Joshua Root)

Summary: postgresql83 8.3.7 Why are all the executables in libdir?postgresql83: add a variant to install binaries into ${prefix}/bin

Rephrasing summary to be an enhancement request rather than a question...

comment:3 Changed 9 years ago by ryandesign (Ryan Schmidt)

A postgresql-select port would be the appropriate way to implement this feature. Has duplicate #28133.

comment:4 Changed 9 years ago by ryandesign (Ryan Schmidt)

#17150 is also a duplicate in a way.

comment:5 Changed 9 years ago by ryandesign (Ryan Schmidt)

Description: modified (diff)
Port: postgresql_select added; postgresql83 removed
Summary: postgresql83: add a variant to install binaries into ${prefix}/binpostgresql_select port request
Type: enhancementrequest
Version: 1.7.1

comment:6 Changed 9 years ago by jmroot (Joshua Root)

Cc: ryandesign@… added

Why would we need a postgresql_select port? There's no system version of postgres.

comment:7 Changed 9 years ago by jmroot (Joshua Root)

Although the base file still has to come from somewhere, doesn't it. But still, fixing this mainly involves adding select files to the postgresql* ports.

And what's wrong with installing version-suffixed symlinks in ${prefix}/bin as well?

comment:8 Changed 9 years ago by ryandesign (Ryan Schmidt)

Hmm, it hadn't occurred to me that the existence of a system version of something would be a criteria for having a _select port for it. My thought process was: There are multiple versions of PostgreSQL available in MacPorts that can be installed simultaneously. Users want to type "psql" to run a particular one of them. (Or perhaps they want to have scripts referencing /opt/local/bin/psql.) The solution I was proposing was to be able to "port select" one of them to create the appropriate symlink(s).

I have similar separate ideas for the MySQL and PHP ports, which I will bring up on macports-dev later.

The alternative would be to just tell the user to put /opt/local/lib/postgresql83/bin or whatever into their PATH. But then I would ask: why do we let users "select" some software packages (like Python), and for others (like Apache) we make them modify the PATH?

comment:9 in reply to:  7 Changed 9 years ago by ryandesign (Ryan Schmidt)

Replying to jmr@…:

And what's wrong with installing version-suffixed symlinks in ${prefix}/bin as well?

Oh, that's what #28133 says. I missed that. You're right, that's probably fine; let's not consider that a duplicate after all.

For mysql5 which does this, it causes some odd issues... for example running "mysql_upgrade5" (where PATH contains /opt/local/bin but not the long path to the real "mysql_upgrade"), doesn't work, as it expects to then find "mysql" in PATH as well (when in fact only "mysql5" is in PATH in this case); see #20949.

comment:10 in reply to:  8 Changed 9 years ago by apinstein@…

Replying to ryandesign@…:

Hmm, it hadn't occurred to me that the existence of a system version of something would be a criteria for having a _select port for it. My thought process was: There are multiple versions of PostgreSQL available in MacPorts that can be installed simultaneously. Users want to type "psql" to run a particular one of them. (Or perhaps they want to have scripts referencing /opt/local/bin/psql.) The solution I was proposing was to be able to "port select" one of them to create the appropriate symlink(s).

Is that a technical limitation or convention? I would agree with you from the end-user perspective that it shouldn't matter...

Is there a link somewhere to the docs for _select? I couldn't find anything with a quick googling.

There is also a difference between being able to switch between 2 versions but only having one installed and being able to have more than one installed at the same time. For instance people would want php 5.2 and 5.3 installed simultaneously moreso than with postgres, though I imagine that for *someone* having both installed at once will always be desirable.

I'd think that a convention that installs things under versioned prefixes and then symlinks to the non-versioned would be nice. Ideal would be integrating something like Ruby's bundler which allows you on a per-directory basis to control which items mean what. Both solutions are probably useful.

So something like: /opt/local/bin/pgsql83 /opt/local/bin/pgsql84 /opt/local/bin/pgsql -> /opt/local/bin/pgsql84 [created by select postgresql 8.4]

And then maybe something like: in /myproj/foo .ports

content of .ports =

# alias port [version] psql postgresql 8.4 php php52

And then when you CD into this directory a script would fire that would create a local .portsbin folder with appropriate aliases and munge your path appropriately as well, like: .portsbin/php -> /opt/local/bin/php52 .portsbin/psql -> /opt/local/bin/psql84 PATH=/myproj/foo/.portsbin:<existing path>

That would be boss.

comment:11 in reply to:  8 Changed 9 years ago by apinstein@…

[sorry for the dupe wanted to fix formatting and don't see an edit button]

Replying to ryandesign@…:

Hmm, it hadn't occurred to me that the existence of a system version of something would be a criteria for having a _select port for it. My thought process was: There are multiple versions of PostgreSQL available in MacPorts that can be installed simultaneously. Users want to type "psql" to run a particular one of them. (Or perhaps they want to have scripts referencing /opt/local/bin/psql.) The solution I was proposing was to be able to "port select" one of them to create the appropriate symlink(s).

Is that a technical limitation or convention? I would agree with you from the end-user perspective that it shouldn't matter...

Is there a link somewhere to the docs for _select? I couldn't find anything with a quick googling.

There is also a difference between being able to switch between 2 versions but only having one installed and being able to have more than one installed at the same time. For instance people would want php 5.2 and 5.3 installed simultaneously moreso than with postgres, though I imagine that for *someone* having both installed at once will always be desirable.

I'd think that a convention that installs things under versioned prefixes and then symlinks to the non-versioned would be nice. Ideal would be integrating something like Ruby's bundler which allows you on a per-directory basis to control which items mean what. Both solutions are probably useful.

So something like:

/opt/local/bin/pgsql83
/opt/local/bin/pgsql84
/opt/local/bin/pgsql -> /opt/local/bin/pgsql84 [created by select postgresql 8.4]

And then maybe something like: in /myproj/foo

.ports
== content of .ports ===
# alias port [version]
psql postgresql 8.4
php php52

And then when you CD into this directory a script would fire that would create a local .portsbin folder with appropriate aliases and munge your path appropriately as well, like:

.portsbin/php -> /opt/local/bin/php52
.portsbin/psql -> /opt/local/bin/psql84
PATH=/myproj/foo/.portsbin:<existing path>

That would be boss.

comment:12 Changed 8 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.