On Sat, 12 Jul 2008 18:46:34 -0700 Saleem Abdulrasool <[EMAIL PROTECTED]> wrote: > We could add a new metadata key EXHERES_ERRORS which lists any fatal > errors that have been encountered while sourcing the exheres. In > order to simplify the implementation (and catch all errors at once), > we continue sourcing even when an error has been raised. When this > key is not empty, the exheres would simply be masked.
There were a couple of possibilities I saw for this.
We could have a single EXHERES_BREAKAGES metadata key. You'd manipulate
it using 'exbroken' (or 'exparrot', possibly). If it's non-empty,
Paludis will treat the ID as being masked.
Or we could have EXHERES_DEVELOPER_MESSAGES, for arbitrary text to be
conveyed to the developer, and EXHERES_TREAT_AS_BROKEN, which if
non-empty is a mask.
Either would avoid the 'die in global scope' issue -- when dying in
global scope, no metadata gets passed back to Paludis, so Paludis
treats the ID as having an unknown EAPI.
> deprecated_function()
> {
> exwarning "deprecated_function is deprecated. Please use
> new_function instead"
> }
That's a whole different kettle of fish, since it won't end up in
metadata until the function is called. And we only get metadata on
builtin_metadata.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
_______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
