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.
This is good to know, I was just not aware of this method. How do I
set permissions when in this phase, I assume doing so with the ports
commands will register it?
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.
Ahh, ok, I understand now. Can that copy of .sample to rename to real
file name be avoided? Can I just copy it in as it is named and be
done with it? I do not want .sample files hanging out in /etc in this
case.
Sorry about all this, I was just totally unaware this was even a
possibility.
Or, if nodelay.txt already exists, tell the user to merge in changes
from nodelay.txt.sample.
Of the files, some are to be merged, some are to be replaces. This is
good actually, as it gives me a place to tell the users where the
files are. Perfect.
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.)
Thanks, will look into that port.
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.
Understood.
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).
Does this ever become an issue with .DS files getting in there, and
that would prevent proper ports operations? Or is it only .turd files
that prevent the deletion of a dir? I know a real non leading dot
file will prevent it, and I expect that, but a .* file other
than .turd, how is that covered?
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.
Cool, thanks, this will work.
http://dl.getdropbox.com/u/340087/Drops/07.17.09/Portfile-dea0db16-115619.txt
$port lint
---> Verifying Portfile for ASSP
Warning: Line 109 should say "use_configure no" instead of declaring
an empty configure phase
Is that a big deal? Will I have any issues with just following those
instructions? I think I tried and it did not like the use_configure
command.
I will be installing my own custom launchd item, and not using ports
for this. I have never done this, do I just make a dir called "files"
and put whatever I want in there? I can reference it with {filesdir}?
Thank you.
--
Scott * If you contact me off list replace talklists@ with scott@ *
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
