getting started

[Mike Hearn]

Havoc Pennington wrote:
> The key point of the LSB defining an ABI is to let ISVs know which of
> the zillion things in /usr/lib on a typical Linux system are safe to
> use. Safe means well-maintained, supported, likely to still be working
> in 5 years, etc.
> 
> Much of /usr/lib is most definitely *not* safe in this sense. ;-)
> I'll avoid naming specific libs since the lib maintainer usually gets
> offended.

Yeah, that will be helpful. But, backwards compatibility is so much more 
than what symbols are exported - take the case I discovered 5 minutes 
ago of libgcrypt which has broken backwards compatibility but not bumped 
the major version. The breaking change was that it's no longer totally 
thread safe by default, you have to enable that now. Exported symbols 
stayed the same, yet this change caused Evolution to crash mysteriously:

http://bugzilla.ximian.com/show_bug.cgi?id=66342

There are a whole class of 'undetectable' breaking changes you can make 
like this.

What happens if the LSB specifies a desktop library which then 
accidentally or otherwise breaks backwards compatibility? Does it simply 
not ship it, or does it wait for the upstream version to fix it. What if 
upstream have a different idea of backwards compatibility to the LSB?

> The LSB then goes a step further and has automatic verification tools
> for the ISV app, and for the distribution, to be sure the ISV isn't
> cheating and using unsupported interfaces, and the distribution is
> properly exporting the supported ones. This is very useful to developers
> since we don't get locked in to supporting immature APIs for eternity,
> and useful for ISVs since they don't accidentally use those APIs.

Yes, that will be very useful. Microsoft has something similar, though 
it's a more generic "scan my source code and runtime logs for suspicious 
things" type tool.

> Other than deprecated APIs, I would guess it has a reference entry on
> each function or pretty close. The main gap is tutorial stuff.

Last time I did GTK+ coding (a while ago) I think the not all the 
signals were documented, ditto for some GObject properties. May be fixed 
now though.

>>>	3) conformance test suites
>>
>>How do you test a widget toolkit? GTK has thousands of entry points, and 
>>AFAIK there isn't any formal test suite currently apart from gtk-demo 
>>and a few test programs in the tree.
> 
> 
> There is a GTK+ test suite that Sun wrote. It's in gnome CVS as "gtkvts"
> 
> Not comprehensive, but it checks that the entry points exist and so
> forth.

OK, that's a good start.

I think it makes sense to include real applications in the test suite as 
well. Lots of them ideally, but no <looks sheepish> I'm not volunteering 
to maintain that :)

Thing is there are lots of problems that are really hard to detect using 
a test suite - the semantics of an interface change rather than the ABI. 
Having a large battery of application tests helps detect these though 
unfortunately it's really hard to automate. Probably not even possible, 
I believe Microsoft just have teams of people which install and test as 
many apps as they can to find problems.

thanks -mike