On Jul 13, 2009, at 23:39, Scott Haneda wrote:
It seems there is a pretty strong desire to put config files into /
opt/local/etc or equivalent. I can see that being the case with
apache, or bind, and other software that generally works with that
in mind.
Yes, config files generally go in ${prefix}/etc. Note that apache2
actually has its config files in the nonstandard location ${prefix}/
apache2/conf; I don't generally recommend creating new ports that
ignore the ${prefix}/etc convention. A subdirectory of ${prefix}/etc
would of course be fine, and appropriate if there are multiple config
files.
ASSP is a self contained application, with files, that loosely can
be called config files. They can not be moved, that would require a
lot of patching to the ASSP software, and would imo, create
confusion to the end user. MacPorts is largely being used in this
case take take advantage of installing several p5's, the fact it
installs ASSP, is almost a nicety.
I think the only way to explain this so I get it right, it to step
through it, bare with me on the length of this email...
ASSP ends up living in /opt/local/var/ASSP/
Installed files:
assp.cfg
assp.cfg.defaults
assp.pl
docs/
errors/
files/
images/
logs/
move2num.pl
notes/
notspam/
okmail/
pb/
quarantine/
rebuildspamdb.pl
reports/
spam/
stat.pl
assp.cfg needs to never be touched by ports once installed.
Then don't copy it into ${destroot} in the destroot phase; copy it
from assp.cfg.defaults directly into ${prefix}/wherever in the post-
activate phase.
According to the docs, an update is to do the following:
- invalidptr.txt
- URIBLCCTLDS.txt
- nodelay.txt (merge)
- redre.txt
- ipnp.txt (merge)
- blockreportuser.txt
- validptr.txt
- bombre.txt (merge)
- whiteorg.txt (merge)
- strictspf.txt (merge)
- invalidhelo.txt
So the non merge, are safe to replace, the merge are not. In these
cases, if I could simply let ports replace them, and as long as a
backup of the entire /opt/local/var/ASSP directory was made, I
would be happy with that and a UI message that said which files
needed to be merged.
* By merge, they mean, append your changes to the file. I would
rather not get in the business of teaching ports how to merge those
files, and leave that to the user.
There are some other cases, but understanding how to deal with
these should suffice. If I can rely on new files that were made
after assp was installed staying untouched, then the app generated,
and user generated data is safe.
It looks to me, like I have a limited set of files I need to make
sure are not touched by ports.
The idea of registering these files as .sample files, and asking
the user to change them, completely destroys the way that ASSP is
designed to work.
I don't understand why; it's exactly the solution to your problem. In
the destroot phase, don't install a nodelay.txt; instead, install a
nodelay.txt.sample. Then, in post-activate, copy nodelay.txt.sample
to nodelay.txt and tell the user about it. Or, if nodelay.txt already
exists, tell the user to merge in changes from nodelay.txt.sample.
See the php5 port for an example of this. (Well, I don't copy the
file for the user, but I do tell them to either copy it or merge it
depending on whether the file already exists or not.)
I would consider them more preferences, than config files, and with
any preference file, it will contain some defaults, be written to
by the user, and should not be messed with on uninstall of an app,
and only sometimes modified on upgrade, if a format changes.
I don't see the distinction between a preference file and config
files. Whatever you call it, they are files containing data unique to
the user and should not be overwritten by MacPorts on upgrade.
Therefore, don't register them to the port as part of the destroot.
Is destroot.keepdirs really only for directories, or can it be
applied to files as well?
Yes, destroot.keepdirs is only for directories. It has no meaning for
files.
The destroot phase works as follows:
First, MacPorts creates the ${destroot} directory and a bunch of
empty directories inside it for the various places ports are likely
to install files. Basically the entire hierarchy, such as ${prefix}/
bin, ${prefix}/include, ${prefix}/lib, ${prefix}/share/man, etc., is
created for you, so that you don't have to make these directories
manually in the destroot phase of every port.
Next, the pre-destroot, destroot, and post-destroot phases run,
during which your port is to put files into the right places within $
{destroot}.
Finally, MacPorts removes any empty directories in ${destroot}.
If there are directories you would like to keep, even though they are
empty, you use destroot.keepdirs, in response to which MacPorts
creates a .turd_${name} file in each directory. Thus, when MacPorts
gets to the part where it removes empty directories, it will not
remove these "kept" directories, because they are not empty, because
they contain a file (the .turd_${name} file).
I think what I really want to do, is just unregister a list of
files form the port after the first time it is installed. Maybe
there is a way to trick ports into doing this by copying a file in
during a certain phase but just keeping the name the same?
I can only reiterate: if you put the file in the ${destroot}
directory during the destroot phase, the file is registered to the
port. If you don't want the file registered to the port, don't do that.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
