On Sep 18, 2009, at 11:13, Olivier Le Floch wrote:
On 18 sept. 09, at 02:17, Rainer Müller wrote:
On 2009-09-17 23:26 , Ryan Schmidt wrote:
Personally, I prefer to tell the user where the sample files are so
they can make copies if and when they want. Other port authors have
taken recently to copying the sample files for the user.
If the software requires the config file to run at all, it makes
sense
to copy it in a post-activate phase. Otherwise, there is no need to
do this.
The point of phpMyAdmin is to administer MySQL servers, so I don't see
any point in trying to run phpMyAdmin without first having configured
it to know where your MySQL servers are...
I agree. In the case of the phpMyAdmin port, the configuration file
is not required, but since phpMyAdmin expects its configuration file
to be in it's root directory (i.e. in /opt/local/www/phpmyadmin/ for
macports), uninstalling/upgrading phpmyadmin would destroy/conflict
with the user's configuration file. Because of this, I had to add a
symlink from the default configuration file location to somewhere in
${prefix}/etc/. Unfortunately, phpMyAdmin calls it's configuration
file {{{config.inc.php}}}, which meant I had to rename it (and
differ from phpMyAdmin's documentation) in ${prefix}/etc/, and the
easiest way I think to document this name change was to directly
install the sample config file.
I didn't quite understand: why did you have to rename config.inc.php
and differ from phpMyAdmin's documentation? Sure it might be nice to
have the config file in ${prefix}/etc along with other programs'
config files, but I don't see what forced you to do that. It would
have been fine to keep the config file where it was, no? Also I think
it's pretty usual for web apps to have their config files within their
own directories, and not within ${prefix}/etc. I haven't sampled many
web apps, but I would assume they're written to be used on web hosts
where users don't usually have access to system-wide directories like /
etc.
phpMyAdmin seems to work with the symlink and no configuration file,
but that would still leave it to the user to understand in what
custom location the config file was to be put, so I'm under the
impression that this would be the best solution for the user while
still complying with macports guidelines.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
