--6JAe/4X0qssghT2u
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 20, 2005 at 03:35:15PM +0300, Mike M. Volokhov wrote:
> On Wed, 20 Apr 2005 14:00:20 +0200
> Quentin Garnier <cube@cubidou.net> wrote:
>=20
> > On Wed, Apr 20, 2005 at 02:51:07PM +0300, Mike M. Volokhov wrote:
> > [...]
> > > 1) Split package on three chunks - xmlformat-ruby, xmlformat-perl,
> > > xmlformat-docs. Latest package will contain only support documentatio=
n,
> > > independly what kind of script you use. The xmlformat-ruby and
> > > xmlformat-perl will be bounded together via PKGALTERNATIVES framework.
> >=20
> > That's what you should do, I think, except for the part that involves
> > alternatives:  a user will want either versions, not both, unless it is
> > a package likely to be used by some other packages that might invoke it
> > in Ruby or PERL.  In the latter case, both versions should be installed,
> > or each package installing an appropriately named version of the script.
> > Again, no alternatives framework involved.
>=20
> Hmm... Seems I haven't understand alternatives job. When we have two
> programs created to solve just the same tasks in the same way, for
> example, editors nvi and vim, it's time to use alternatives, right?
> But now we have just the same programs, both should be better installed
> as bin/xmlformat. Why not use alternatives here? Moreover, who want to
> have both nvi and vim? But alternatives were defined there...

nvi and vim are different programs that offer a common interface to do
similar things.  In your case, one program is offering two interfaces to
do the exact same thing.  While I get your point, using the alternatives
framework look like complete overkill to me.  But in the end it is your
choice anyway.

> > > 2) Use variable named, say, USE_LANG which may be set to "ruby" or
> > > "perl" at the build stage. Resulted package name may be also dependent
> > > on the selected value for USE_LANG. The conflicts will be also handle=
d.
> >=20
> > In that case, the correct way of doing this would be with the
> > PKG_OPTIONS framework.
>=20
> Yes, that's it. Thus yet another question about PKG_OPTIONS. Is it
> possible to create mutualy exclusive pkg options? This might be useful
> for option switching.

You can test on ${PKG_OPTIONS} and then set PKG_FAIL_REASON.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--6JAe/4X0qssghT2u
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQmZTWNgoQloHrPnoAQKdPQgArg+zU5DmntBp/eRta+5sxu654EFtA49V
yOmzVmNtS/M0wv8aytdCABIr5OBnQe+iYMx0pwTtBrOPrkRnD84I+f1udzedUjJT
XOcYAdAJGYAaRVwbFJpUjSL+ErKcsetAXAMXjG8YbXNyoV59uwvues2JopMbe4c4
YE3q++20eAR0gWvyBsqtxlderGnebeh0lXMaUzkqq65gCCCz7pkAhSSng3XI3Olb
DivYg5Sgp0513rE8mPvkfa1E+53r4o9BdkscxNFAHOaEbwZ8RDr4ouYY1w2cmJeF
QPjRALjHljicEOK8nbT77JoG2a1u2QSsjL/rusEbkCftfGcssrWB9w==
=HAH9
-----END PGP SIGNATURE-----

--6JAe/4X0qssghT2u--