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 committee. > > 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 system. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature