Thanks for the other reply Bryan, I will combine my comments here,
rather than opening an entirely new email, since they are so closely
related.
On Jul 13, 2009, at 7:52 PM, Ryan Schmidt wrote:
On Jul 13, 2009, at 20:55, Scott Haneda wrote:
It is about time for me to learn about the port upgrade process.
My ASSP port file is complete, and working as far as installs go.
There may be some bugs in ASSP, or the perl modules, that I can not
figure out, but the port itself is solid.
My next step is to make sure that upgrades are smooth.
[snip...]
[snip...]
So simply anything you put in the destroot will be registered to the
port. If you uninstall or upgrade the port, the items that were
registered to the old version of the port will be removed.
So you would not want to register configuration files or log files
or the like to the port. Instead, you would register sample versions
of the configuration files to the port, and either advise the user
to make a copy of these files, or do so for the user upon first
installation if they don't already have them. The whois port
demonstrates the former strategy while apache2 shows the latter.
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.
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.
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 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.
Is destroot.keepdirs really only for directories, or can it be applied
to files as well? Is that the preferred method here, to simply create
a list of files I want to keep and iterate them with
destroot.keepdirs? This protects those files from any modification at
all when performing upgrade or uninstall?
Or perhaps I do something like this:
post-activate {
set keepers {list of files I want to keep}
foreach keep $keepers {
if {![file exists ${keep}]} {
file copy ${keep} \
${assp_base}/${keep}
}
}
}
That is probably syntactically wrong. I am not sure if that is right
either, and it makes sense to me how that would deal with a new
install, but not a upgrade, or a uninstall.
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?
Thanks for the guidance, I am almost there.
--
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
