[lsb-discuss] An idea to kick around for brainstorming purposes....

Theodore Ts'o tytso at mit.edu
Thu Feb 5 07:31:22 PST 2009

This is one of these ideas I had while in the shower, so please take
this for what it's worth....

There are a huge number of people writing shared libraries, especially
for the desktop, or for the mobile environment, as they saying goes,
"They have us outnumbered".  We can't possibly cover them all for
resource reasons, and besides, many of them won't become commercially
significant (although they might be used in any lots of open source
desktop applications), either forever, or for a very long time.  While
they are in that state, life becomes non-ideal for people who have to
deal with ABI breakages, and for the small handful of applications that
are trying to use the bleeding edge desktop libraries.

For example, Lotus Notes 8.5 works fine on Ubuntu 8.04, but all text on
a particular part of its UI doesn't for if installed on Ubuntu 8.10 due
to some toolit change[1].

[1] http://www-10.lotus.com/ldd/nd85forum.nsf/5049ee164c54799785256bff00519260/2344df461119eb00852574fe0040f5fe?OpenDocument

So, what to do?  Obviously, we need to spin off more of the LSB work to
the the upstream developers.  If we make the tools valuable enough that
they want to use them for their own sake, even if we choose not to
include their library in a near-term LSB, it makes the ecosystem better,
and when their library *is* ready to be included in the LSB, it's less
work for us to pull it in.

How to do this?  Currently, our infrastructure is heavily centralizied;
we have a single, centralized database, which drives all of the tools.
What if we had something which used essentially the same schema, but
only provided the necessary information for a single stand-alone module.
So for example, suppose we had this technology three years ago, or
whenever DBUS was first getting some serious attention.  And let's
suppose were able to get the meme out there about how stable ABI's were
important, and the DBUS developers were interested in doing this.

If they could download a standalone environment where they could
document their API's as they went along, adding them to some database
(perhaps even using SQLite, as it's less overhead to set up than MySQL,
and they only need for their very small module), and they could easily
create tests as they go along, we might have had a situation where when
they were ready to submit it to the LSB, the work might be much easier
to important since it's roughly in the right schema organization to
begin with.

And in the meantime, if they could use that database to create simple
ABI tests, they could detect ABI breakages while they were developing
their library, so they would at least *know* if they were breaking
something --- thus making the world nicer even if their library was
never accepted into the LSB proper.

So the question is:

*)  Is this idea on crack?

*)  How much work would it be to adopt our tools so it might be the
beginnings of such a thing?   

*) I'm assuming that it's probably more than a Google Summer of Code
project, but is there some subset which could be done as a GSOC?

*) What other changes could we make to make this no harder for an OSS
 project to start using?   The idea is that it should be roughly at the
 same complexity and utility as autoconf, libtool, Doxygen, etc., so it
 becomes an accepted part of the infrastructure used by OSS projects.

 	    	     	     	 		     - Ted

More information about the lsb-discuss mailing list