On Feb 27, 2009, at 06:59, Scott Haneda wrote:
On Feb 27, 2009, at 4:42 AM, Ryan Schmidt wrote:
On Feb 26, 2009, at 19:24, Scott Haneda wrote:
My ASSP portfile I have now, instead of using xinstall, I just
copy the directory into place. I need a little guidance no the
best way to do this.
ASSP will end up in /opt/local/var/ASSP
If ASSP is not there, I just move the entire distro in. On first
run of ASSP, a few files and folders are made, the user is good
to go.
How do I deal with updates to ASSP? The files that were made on
first run, as well as config files that have been edited over
time, can not be replaced.
I believe if I do this as a entire directory, I am going to mess
up, unless there is a merge or sync command I am not seeing.
Would it then be correct to simply install each file one at a
time, then they get registered, and the port upgrade can just
touch those files, leaving any user created files in the same
area alone?
It does not matter how you put files into the destroot, whether
it's by file copy or xinstall or make install or whatever. As long
as files are in the destroot, MacPorts will see them and register
them to the port.
Ok, thanks. I will have to think the best way to do this then.
You should not install any files the user will modify, because
they will be deleted and overwritten by your port's new files if
they upgrade the port. Instead, install sample files which the
user is to copy and then modify.
I hope there is a provision for dealing with this. ASSP has a built
in http server, done in perl, which allows a web based admin. That
admin, reads and writes files in the ASSP/files, ASSP/db and a few
other places. The user is not modifying them directly, they are
more like "preferences" for ASSP.
There are no sample files to install, they are sparse config/
instruction files, that get filled over time, either by the user
admin, or automatically by the application, or both.
How do I protect these files? I suspect this is analogous to how to
you protect mysql databases, but those are not pre-installed in
most cases.
You "protect" these files by having the port not install them in the
destroot.
You can install samples of these files in the destroot with different
names or in a "sample conf" directory. In the post-activate phase,
you can check if the user already has copies of these files in the
locations where the software will use them. If not, you can copy the
files there (since you're doing this in post-activate and copying
directly to ${prefix} these files will not be registered to the port).
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
