[Exherbo-dev] support dying in eclasses in global space
ciaran.mccreesh at googlemail.com
Sun Jul 13 20:49:55 BST 2008
On Sat, 12 Jul 2008 18:46:34 -0700
Saleem Abdulrasool <compnerd at compnerd.org> 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.
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: not available
More information about the Exherbo-dev