[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linux Core Consortium

On Tue, Dec 14, 2004 at 11:53:54AM -0500, Ian Murdock wrote:

> > > What about the LCC's scope isn't clear?

> > Er, the fact that no actual scope has been stated?  What does "core" mean?
> > What packages (libraries) are included in this "core"?

> "Core" means "implemention of LSB", and the packages/libraries that will
> constitute that are being determined now, as a collaborative process.

Well, for instance, the libacl package was brought up as an example in the
context of changing library SONAMEs/package names.  The current LSB has
nothing to say about this library; it covers only glibc, libstdc++, various
core X libraries, zlib, libpam, libgcc, and ncurses.  So there was some doubt
in my mind as to how broad a "core" ISVs were actually demanding be
specified, as well as doubt regarding the conclusion that the LSB process
was flawed if the simple fact was that ISVs were demanding standardization
of libraries that no one has asked the LSB to address.

I still think "implementation of the LSB" is a murky concept; the LSB
specifies very little about kernel behavior after all (though some things
are implicit given the description of libc ABIs plus the de facto glibc
implementation of them), so I don't know whether and how many userspace
tools it's also seen as essential to cover.

> I assumed Debian would want to be involved in this process too, rather
> than being presented with a more well-defined scope as a fait accompli..

Particularly considering involvement in the LCC would require essentially
unanimous consent of the maintainers of the covered core packages, I think
it's impossible for Debian to be meaningfully involved without first having
a clear understanding of what would be expected of us -- especially when
late bouts of scope creep could hamstring the entire effort by suddenly
requiring the consent of a new package maintainer who doesn't approve!  I
think it's better if this can all be laid out up front so we can get a clear
yea or nay from the affected maintainers before sending people off to

> > If so, and given that
> > these are very likely outcomes, what reason remains for Debian to get
> > involved in the LCC if it's not going to result in any ISVs supporting
> > Debian as a platform through the LCC effort?

> At the very least, the differences would be smaller than they
> otherwise would be, and that can only be a good thing for
> LCC, Debian, and the Linux world as a whole.

On the contrary, I think that providing a single binary platform
representing an overwhelming majority of the Linux market share that ISVs
can write to, rather than enforcing the rigors of writing to an open
standard such as the LSB, makes it much more likely for ISVs to demand
bug-for-bug compatibility with the LCC binaries; which means that anyone not
using the certified binaries is just that much farther up the proverbial
creek.  Keeping the differences small is only a benefit if ISVs do choose to
test against Debian as well as against the LCC.

> And, who knows, with Debian participation, perhaps the differences would
> end up being small enough and the processes, methods, and
> mechanisms defined such that it's no longer a "very likely outcome".

I think that accepting outside binaries for core packages would be regarded
by many in the community as devastating to Debian's security model.  I think
that requiring immutable sources for core packages would be equally
devastating to Debian's development model.

> > (If you see ways that Progeny
> > would benefit from Debian's involvement in the LCC even if the official
> > Debian releases are not LCC-certified in the end, I think that's relevant
> > here; but I would like to know how you think it would benefit Progeny and
> > other companies building on Debian, and why you think that Debian itself
> > warrants representation at the table.)

> As I said at the very outset, one possible way forward is to simply
> produce a Debian-packaged version of the LCC core independently,
> and to make sure that core is 100% compatible with Debian (i.e., you
> can take any Debian package and install it on the LCC Debian core
> and get the same results as if you'd installed it on Debian itself).

I would prefer to take this a step further in the opposite direction.  Given
that the LSB specifies a determined linker path as part of its ABI other than
the one used by the toolchain by default, and given that the kernel is
largely an independent, drop-in replacement wrt the rest of the packaging
system, why *couldn't* we provide the LCC binaries in the same fashion as the
current lsb package -- as a compatibility layer on top of the existing
Debian system?  This sidesteps the problem of losing certification over
small divergences that significantly impact our other ports and is a much
more tractable goal, while still giving us a target to aim for with our base

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: