Error handling

Bryan Dumm bdumm at
Tue Jan 9 10:02:41 PST 2001

On Tuesday 09 January 2001 11:46, you wrote:
> On Mon, Jan 08, 2001 at 08:20:08PM -0500, Gerard Beekmans wrote:
> > > But in general, that should probably be left for the frontend to do.
> > > Backend should just inform it that the error occurred.
> >
> > As you may have read in the roadmap on alfs site, at the error
> > checking/logging phase the backend should not just inform about an error
> > but try a couple of known ways to overcome the error (ie: if it comes
> > across "-lncurses" not found during static bash, have it check to see if
> > the libncurses.a symlink is missing and if so, create it, or have it link
> > iwth the libcurses.a file instead (requires a sed-like operation on
> > Makefile)). This "known problems+fixes" list will increase at time as we
> > encounter more problems so the backend will become smarter. But, in light
> > of being able to have more than one backend the backend should remain a
> > simple thing perhaps. So that problems+fixes part should be dealt with in
> > some other way.
> I see. It seems that I missed that part. :)
> It's a great idea BTW. Was it already discussed?
> I mean I'm curious about, for example, where will this list be? Part of the
> profile or in a separate file/profile? And stuff like that.
> Maybe a "common attribute" :
> 	<config dir="&LFS;&builddir;/bash-2.04" ...
> 		error="/profile(s)/to/be/executed/if/tag/fails.xml" />
> or something similar? Backend won't become any smarter/more complicated
> like this. He'll again just follow the profile(s).

Ok I got a new idea... :)

Let's build a "user profile" vs a system/package "profile". 

This way we can do several things. 

1. Let the user decide on all these and other such details
2. Send the user profile along with the system/package profile
3. Let those two decide for the backend what it does.....


More information about the alfs-discuss mailing list