Date: Fri, 19 Apr 2002 11:28:27 -0700 (PDT) From: David Wolfskill <david@catwhisker.org> To: freebsd-ports@freebsd.org Subject: Port-building guidance requested: optional sources? Message-ID: <200204191828.g3JISRmV033066@bunrab.catwhisker.org>
next in thread | raw e-mail | index | archive | help
There is a port for which I'm the maintainer (astro/gpsman). I was
recently working with someone who was using the port, as well as the
original author of the software, in order to find a nice, clean way
to extend the software in a useful way.
We pretty much figured out what change needs to happen to the software
(2 additional lines of code, one of which is blank :-}); the question/
concern I have is on how best to set up the port to take advantage of it.
From looking at the docs, I'd normally obtain or set up some PATCHFILES
and go from there. But the way the software in question is set up for
distribution makes that a bit awkward:
* 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@catwhisker.org
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@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204191828.g3JISRmV033066>