> The only way to usefully communicate that state is ... > > > If Orthanc is configured for PG but PG is not started, > > Orthanc will stop, will *not* fallback to sqlite [, ...] > > ... and will loudly and clearly complain: > > you have configured Orthanc to connect to PG with > $PG_CONN_STRING but I cannot connect with those > parameters, here is what libpq had to say: > $LIBPQ_ERROR_MESSAGE (if any)
Yes, this is the current behavior: >>>>> # cat /var/log/orthanc/Orthanc.ERROR E0305 17:02:20.518434 30901 PluginsManager.cpp:144] Error in PostgreSQL: FATAL: password authentication failed for user "postgres" E0305 17:02:20.518726 30901 PluginsManager.cpp:82] Error while initializing plugin /usr/share/orthanc/plugins/libOrthancPostgreSQLStorage.so (code -1) E0305 17:02:21.014979 30901 main.cpp:654] Uncaught exception, stopping now: [Error while using a shared library (plugin)] <<<<< > So, all in all the only useful purpose an orthanc-PG package > might serve is to Depends: on postgresql-*client* thereby > ensuring libpq is installed :-) thereby freeing the > orthanc(-core) package from that Depends:. Yes, this is also the current state of the package. > you might just do away with the whole gamut and have > orthanc(-core) just install everything (core and PG plugin) > and also Depends: on sqlite _and_ postgresql-client. It would > then provide a default configuration for sqlite and a > correct-but-inactive configuration for the PG plugin. I do not want to include the PG plugins inside orthanc, as the two projects are fully separated (distinct repositories, distinct versioning). OK, so, according to the KISS principle, I think I will choose the simplest way. There will be 2 packages: "orthanc" and "orthanc-postgresql", and I will discard "orthanc-sqlite". It will always be possible to introduce it in the future. I will also remove the "Conflicts:" and provide instructions/samples to modify the "/etc/orthanc/orthanc.json" file to enable PG support. This should hopefully be ready for this afternoon. Sébastien- -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2006816440.12702165.1425637451850.javamail.r...@chu.ulg.ac.be