Flavoring p5-DBD-Pg -- burned by a perl upgrade

All,

Dayjob is an open source software company, and runs RT with Postgres.  We use it in production, to sell support for the open source software we make.  

We are proud of this, and moved to a commercial solution, then *back* to RT.  Thus we require p5-DBD-Pg.

p5-DBD-Pg is not flavored, and is only built against the default version of postgres.  This port doesn’t change much, but it requires a reinstall whenever the version of perl changes, since the directory for perl’s modules changes.

Dayjob does not want to have to dump and restore our fairly large RT databases every time the postgres default bumps (presently, we have a machine on 15, and the default is 17).

Dayjob also does not want to have to poudriere build ALL of the dependencies for rt50, just to keep up with one database driver, when everything else we run is pretty much stock.  (Since there’s not a good way to say “use the private ports repository for just this one port, and base for all other things").

What would it take to flavor this?  I maintain a few paltry ports, but there’s not real good documentation I’ve found for how to start flavoring a thing when it’s not already.  (There’s a /usr/ports/Mk/Uses/mysql.mk — there’s not one for postgres, and it’s not a huge file, but it also doesn’t look trivial)

We *could* just keep our ports tree up to date on this box and build just this one port against a given postgres, but that also feels sloppy.

What’s the “best practice” in this situation.  How much coffee/chocolate/beer do I need to buy sunpoet to avoid this problem in the future?

-Dan
PS: I’ll be at BSDCan, hope to see y’all there.