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.
ASSP is a copy to install type of app, you unzip it, move the files
in place, and start it, that is all there is to it. It comes with
a healthy list of perl dependencies, but as long as those are in
place, it works.
MacPorts is largely in this case, being used to avoid the problems
a lot of mac users had with CPAN, and get all the perl bits in place.
Largely, when ASSP is updated, only one file will be updated, which
is assp.pl, the core application for the proxy.
My install essentially unpacks, and loops through all the files in
the distribution. Some need removing, as they are windows
specific, some need reinplacing to change the perl chebang, and
some need some line endings patches up.
ASSP comes with for example, a greylist.txt file, in it will be a
list of hosts that are to be excluded from greylisting. There are
many other files that are like this, that is one example. This
file is also assumed to be edited by the end user, either by hand,
or via the web admin that assp.pl provides.
ASSP will create log files, I know that an port upgrade assp will
leave those alone, I believe even an uninstall will leave those
alone. But what is the procedure for upgrades? I would not want
greylist.txt touched.
What happens if there is an introduction of a new file, that will
need to be copied in place? What happens if there is an
introduction of a existing file that needs to be over-written?
I am looking for suggestions on how to best make this a solid and
stable process for users of this port file.
During the destroot phase, your port must stage its files into the
directory identified by the ${destroot} variable. Since ports should
generally put things inside the MacPorts prefix, that means you will
usually be copying things to some place under ${destroot}${prefix},
e.g. a program the user is expected to run might be installed into $
{destroot}${prefix}/bin
During the install phase, MacPorts takes everything in the destroot
and copies it to a location in ${prefix}/var/macports/software/$
{name} (in a directory named for the version, revision and selected
variants)
During the activate phase, MacPorts makes hard links from the thing
in ${prefix}/var/macports/software/${name}/... to the corresponding
place in / and in the deactivate phase, MacPorts removes those hard
links again.
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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
