[no subject]

* The base software is distributed as a gzipped tarball, as normal; the
  filename is even the expected one from the ${PORTNAME}-${PORTVERSION}
  construct.  So far, so good.

* However, the changes are not distributed as patchfiles; rather, it's
  a separate gzipped tarball named "update_5.4.2.tgz" (though that file
  is in the primary of the ${MASTER_SITES}).

* In the normal course of events, the idea is that immediately when a
  new release of GPSMan is made, there will not be one of these "update_*"
  files.  As bugs get fixed and small features are added, replacements
  for the relevant files will be tarred up and made available.  (Note
  that the existence of a FreeBSD port for the software is fairly recent,
  and is not the primary focus for the software in question.  Also, none
  of this is compiled code, in case that matters:  it's Tcl.)

  The point is, the existence of the "update_*" is not constant one way
  or the other.

* Since I (well, someone) would need to be changing the port for any
  change to the software anyway, I could do things in a "brute force" way,
  and for a new release, remove the logic in the Makefile to get & work
  with the update_* file; when the first update becomes available, I
  could add the logic back in (until the next release), and so on.

  But I would prefer to keep the essential framework of the port fairly
  constant.  I fancy it less likely to be error-prone that way.  :-)

* One approach that comes to mind (other than the "brute force" one)
  would be for me to make a patchfile for each file that shows up in the
  update_* tarball, and thus let relatively "normal" ports mechanisms take
  over.  I gather that if I were to do this, each patchfile would be
  distributed as part of the port (i.e., it would be there whether the
  gpsman port is installed or not), which could be somewhat annoying to
  some folks.

So:  Is there a "cleaner" way to work with this than either the
"brute force" or the "bunch of patchfiles" approaches I sketched
above?

Please Cc: me if you write to the list, as I am not subscribed to
-ports.  If folks write to me without including -ports, I'll summarize
back to -ports.

Thanks,
david
-- 
David H. Wolfskill				david@xxxxxxxxxxxxxx
Based on my experience as a computing professional, I consider the use of
Microsoft products as components of computing systems to be just as
advisable as using green wood to frame a house... and expect similar results.

To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-ports" in the body of the message