On 17 Dec, 2017, at 11:10, Yuri <y...@rawbw.com> wrote:
On 12/17/17 06:32, Adam Weinberger wrote:
Ah okay. Then I'd say, make a slave port that just
fetches/extracts/installs the data files, and an option in the Geant4
master port that defaults to off. Set the slave port to NO_PACKAGE.
Ok, I will do it this way.
I wouldn't go the flavor route, because the purpose of flavors is to
generate multiple packages. The 4.5GB data files shouldn't have a
package, so options is the way to go.
I was actually wondering, why the use of flavors is such a bad idea in
this case? I know that flavors weren't originally intended for this, but
it might seem that they lend themselves very well to such use.
One can have a virtual flavor, say @withHugeData. It doesn't get built by
default because it is virtual. At the same time, somebody who needs data
can always run 'poudriere .... thepkg@withHudeData' and build the needed
flavor of the package.
What would be the downside of such use, besides it being the use of a
completely different kind than anticipated?
Hi Yuri,
My reasoning is that options exist to let users configure a port to have
one feature or another. The key point there is that users can choose the
configuration themselves.
Flavors exist to make it easier to produce multiple packages without making
slave ports. The key point here is producing multiple packages. Presumably
you'd set NO_PACKAGE on the massive data, so producing multiple packages
isn't a benefit. If you're not looking for the builders to produce multiple
packages, flavors just isn't the optimal paradigm.
A NO_BUILD slave port is really easy for people who are normally pkg-only.
There's no dependencies, just fetch/extract/install. I'm assuming that
Geant4 has a number of dependencies, and it's a much bigger deal for people
used to pkg install'ing everything.
The other thing you might consider is a simple shell script to fetch and
extract the data files into place. net/GeoIP does it like that (though not
for size reasons).
# Adam
--
Adam Weinberger
ad...@adamw.org
http://www.adamw.org
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
