[gentoo-dev] virtual/ocaml - to be or not to be

[gentoo-dev] virtual/ocaml - to be or not to be

[Ingo Bormuth]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]


Hi dev-list,

what is the rule concerning when to introduce new virtuals?

I created an ebuild for metaocaml which is a real drop in replacement for 
the ocaml programming language allowing for metaprogramming and dynamic 
linking. Metaocaml in fact is a patched version of ocaml.
For licence reasons the patch is not available so I cannot optionally 
apply it in the ocaml ebuild.

Would you in such a case create a new virtual or just 
PROVIDE "dev-lang/ocaml" in the metaocaml ebuild ?

More information: Bug #111407

Thanks Ingo


-- 
Ingo Bormuth, voicebox & telefax: +49-12125-10226517       '(~o-o~)'
public key 86326EC9, http://ibormuth.efil.de/contact   --ooO--(.)--Ooo--

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] virtual/ocaml - to be or not to be

[Alec Warner]

Ingo Bormuth wrote:
> Hi dev-list,
> 
> what is the rule concerning when to introduce new virtuals?
> 
> I created an ebuild for metaocaml which is a real drop in replacement for 
> the ocaml programming language allowing for metaprogramming and dynamic 
> linking. Metaocaml in fact is a patched version of ocaml.
> For licence reasons the patch is not available so I cannot optionally 
> apply it in the ocaml ebuild.
> 
> Would you in such a case create a new virtual or just 
> PROVIDE "dev-lang/ocaml" in the metaocaml ebuild ?
> 
> More information: Bug #111407
> 
> Thanks Ingo
> 
> 

For a small number of deps ( IE 2 providers ) you can use an || depend atom.

|| ( dev-lang/ocaml dev-lang/metaocaml ) -> for example

Regardless of the outcome ( virtual vs no virtual ) the virtual should 
be a new style, and not an old style virtual.  I would say one is not 
necessary here however.
-- 
gentoo-dev@gentoo.org mailing list