Re: Linux Core Consortium
On Wed, 2004-12-15 at 07:42 -0800, Steve Langasek wrote:
> > "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.
Doing an apt-cache showpkg on libacl1, I see coreutils depends on it. I
don't see coreutils in the list of dependencies of the "lsb" package,
so I assume it's implicitly pulled in by one of the other dependencies,
since LSB 2.0 does require ls and some of the other commands provided
by coreutils. So, by following the dependencies, libacl1
would be in that core too even if the LSB has nothing to say about it.
> 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.
Yes, it's murky, but as you point out, and as the libacl1 example shows,
there's still considerable room for interpretation while remaining
LSB-compliant. We're trying to make the LSB stronger and more tangible
by building a reference implementation that software developers and
ISVs can target, knowing that what they're targeting is in use in the
real world and not just a "sample implementation" that may differ
dramatically from the LSB-certified distros their customers are using.
> > 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
> committee.
I agree, and I probably pushed too strongly on my "ideal scenario",
which no doubt led to the "all or nothing" perception that seems to
be prevailing in this thread.
The right thing to do now is for interested parties
within the project to begin discussing what Debian would want in the
core, development processes, etc., and to engage the LCC as a
separate group and/or as individuals to make sure Debian has a voice.
Whether Debian uses or is at least influenced by the result of the
LCC's work down the road should be a separate question, though it's
a strongly related question, because if "what would be expected of
us" turns out to be unrealistic or unachievable, the former will
be a non-starter. That's why Debian's voice needs to be heard now.
> > 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
> system.
That's certainly a way forward too, and we will explore it.
--
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/
"All men dream: but not equally. Those who dream by night in
the dusty recesses of their minds wake in the day to find that it was
vanity: but the dreamers of the day are dangerous men, for they may
act their dreams with open eyes, to make it possible." -T.E. Lawrence
Reply to: