New squil ports

[Wesley Shields]

On Fri, Apr 04, 2008 at 11:35:59PM -0500, Paul Schmehl wrote:
> I'm the port maintainer for security/sguil-sensor, security/sguil-server 
> and security/sguil-client.  These ports go together and need to be updated 
> together.  At present, the version is 0.6.1.3.  The new ports will be 
> version 0.7.0 and have some very significant changes from the previous 
> version.
> 
> Also, I am the port maintainer of security/barnyard and the slave port 
> security/barnyard-sguil6 port.
> 
> I have some questions about how to do this update.
> 
> Should I patch the existing ports?  If I do, the committer would need to 
> commit all three ports simultaneously or someone might install mis-matched 
> versions.

If you want to take this approach just note in the PR that all three
must be committed together.

> Should we rename the existing ports to sguil6-sensor -server and -client 
> (or sguil-sensor6 - server6 -client6) and then install the new ones as new 
> ports named as the present ones are?

Only if there is a desire to support/maintain the old version.  If you
want to take this approach you should ask for a repocopy of sguil-sensor
to sguil6-sensor and then have the update apply to sguil-sensor, so that
history is maintained.  Same goes for the other ports.

> Should we rename the barnyard slave port to barnyard-sguil?

If it is not tied to a specific version of sguil then I'd say it should
be renamed (via a repocopy, as to maintain history).

> I'm not sure what the best way is to proceed.

The easiest thing to do would be to update the ports without a repocopy
and note in the PR that the updates must be applied together.  And for
the update of barnyard I'd rename it to remove the "6" if possible.

> A gzipped tarball of the three new ports is attached in case anyone wants 
> to test them.  Inside the tarball is gzipped tarballs of each of the three 
> ports.  DO NOT untar them in /usr/ports/security or you will overwrite the 
> existing ports (which will then be overwritten in turn by your next 
> c(v)sup).

Unfortunately I can't review these changes at this time.

-- WXS