Date: Fri, 03 Nov 2006 16:10:19 -0500 From: Lowell Gilbert <freebsd-ports-local@be-well.ilk.org> To: Charles Sprickman <spork@bway.net> Cc: freebsd-ports@freebsd.org Subject: Re: creating "local" ports (fwd) Message-ID: <44irhwme2s.fsf@be-well.ilk.org> In-Reply-To: <Pine.OSX.4.61.0611031519500.4567@dyn-160-39-250-49.dyn.columbia.edu> (Charles Sprickman's message of "Fri, 3 Nov 2006 15:30:47 -0500 (EST)") References: <Pine.OSX.4.61.0611031519500.4567@dyn-160-39-250-49.dyn.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
You've got a bunch of misconceptions. In this case, that turns out to be good, because the solutions are a lot simpler than you think. Charles Sprickman <spork@bway.net> writes: > Hello all, > > I'm finding that there are a number of ports that we need to patch for > some functionality that's unique to our business (qmail, mailfront, > etc.). Currently we just do "make patch" and then apply our patches. > This works, but is a bit of a pain to maintain. > > Is there a way to create a "local" category? ie: /usr/ports/LOCAL Yes, you can look at category creation in the porters' handbook, but there is an easier approach: just put your own patches in the files directory of the port. This lets you take advantage of changes to the official port. > Is there some mechanism that I'm missing to deal with a local > category? I've been googling without much luck, and I didn't see this > addressed in the porter's handbook. See /usr/ports/Mk/bsd.local.mk; it is the hook that will let you do your category customization without needing to actually modify any official files. > Beyond that, I have a few other questions: > > -By default cvsup and (I assume portsnap) would nuke anything in > /usr/ports that was not part of the main ports tree. Not true. cvsup will only touch files that it thinks *it* originally put in the tree. I haven't used portsnap, but it looks as though the same applies. Therefore... > How can this be > dealt with in a way that none of the current/future port update > methods will not clobber our local tree? it's not a problem. > -How does one handle packages that depend on say, qmail, but I now want to > depend on local-qmail? I know portupgrade can be tought this by setting > an alternate pkgdep, but is there any clever way of doing this so that > when you're not using portupgrade the deps are adjusted? I don't know a way to do exactly this. My advice would be to finesse the problem: either by using portupgrade, or by using the "real" port (e.g., qmail rather than local-qmail) with your own patches, as I explained earlier. I hope that helps.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44irhwme2s.fsf>