2014-08-26 10:30 GMT+04:00 Peter Hessler <[email protected]>: > On 2014 Aug 26 (Tue) at 05:02:41 +0400 (+0400), Vadim Zhukov wrote: > :2014-08-26 4:49 GMT+04:00 Chuck Burns <[email protected]>: > :> On Tuesday, August 26, 2014 1:10:17 AM Vadim Zhukov wrote: > :>> See the pkg_create(1), particularily the "VARIABLE SUBSTITUTION AND > :>> FRAGMENT INCLUSION" part. > :>> > :>> Also, please note that in OpenBSD we usually try to minimize both > :>> number of options and number of optional FLAVORs. > :>> > :>> And the final note: are you sure you want "core" and "client" as > :>> FLAVORs, and not as MULTI_PACKAGES? See the detailed description of > :>> the latter in the bsd.port.mk(5). > :>> > :>> -- > :>> WBR, > :>> Vadim Zhukov > :> Well, they can each be installed together or separately, have no > dependency on > :> each other, but for some reason, the core still wants to install an icon. > :> > :> I figured it'd be easier to just have them as flavors, and default to > installing > :> all three. It's a distributed IRC client, so it will not work as designed > :> without a core running somewhere.. a client running somewhere. Now, the > :> monolithic version simply runs the core internally alongside the client. > This > :> is useful for people who simply like the UI but don't want to have to > configure > :> a server for it. Now, with that said, I suppose I could do away with the > :> monolithic option on OpenBSD. Now, how a couple of Linux distributions do > :> this is they have a "quassel" package with all the common stuff, and > "quassel- > :> mono/server/client" packages that all require the quassel package. > :> > :> The way FreeBSD handles it is, the package simply installs all three parts > no > :> matter what, and the ports system has options for building whatever part > you > :> may actually want. I was hoping to be able to use OpenBSD's flavors to > make > :> this a little more binary-friendly... > : > :Then I say again: take a look at the MULTI_PACKAGES. It's definitely > :what you actually want. > : > :-- > : WBR, > : Vadim Zhukov > : > > As Vadim says, you want MULTI_PACKAGES. > > FLAVOR is when the builds and packages *conflict* > MULTI_PACKAGES is when you can use them together (or seperate) in harmony.
Not quiet that. FLAVORS = "same sorts of a package, different options enabled" MULTI_PACKAGES = "different sets of files in package" FLAVORS may be non-conflicting, see math/fftw. Subpackages (items in MULTI_PACKAGES) could conflict, see an example at deve/jdk. FLAVORS (usually, PSEUDO_FLAVORS) could have influence upon a BUILD_PACKAGES - this is a subset of MULTI_PACKAGES that would be actually built with given FLAVOR and ARCH. -- WBR, Vadim Zhukov
