cyeoh at samba.org
Mon Oct 23 18:36:08 PDT 2006
At 2006/10/23 15:54+0200 Jiri Dluhos writes:
> > An LSB-compliant application is only allowed to assume that facilities
> > guaranteed by the LSB will exist.
> Yes, but only in theory. In practice, strict imposing of this rule is both
> infeasible and dangerous.
> If we strictly mandate that LSB-compliant applications must use only
> LSB libraries, it would paralyze the whole system development. We
> will then get a classical bureaucratic deadlock (you cannot put a
> library into LSB until it becomes known practice, and it will never
> become good practice if it is not used, and it cannot be used before
> it is in the LSB).
But not imposing these restrictions is even more dangerous. If you
allow applications to rely on features outside of the LSB there is a
very high risk that the application will not work either at all or in
the same way on different distributions.
If a library does exist on multiple distributions and ISVs would like
to use it but currently are unable to do so (and have workarounds),
then we need to go through the pain of standardising it and developing
good test suites for it.
> Apart from this, the current LSB building environment is simply not powerful
> enough for building even some very basic Linux packages - coreutils is the
> most notable example.
Yes, this is an area that could definitely do with a lot more effort
concentrated on it (and really always has needed a lot more time spent
> We have about five well-tested, working package systems. Why, for
> the heaven's sake, should every application vendor write their own
Agreed! But this is a separate project. Its development could be
facililated by the LSB, but the LSB should not rely on it until itr is
ready and widely accepted. This is also a *huge* project, it has been
tried several times before just within the LSB context.
cyeoh at au.ibm.com
IBM OzLabs Linux Development Group, ADL
More information about the lsb-discuss