On Wed, 19 Jul 2000, Anthony W. Youngman wrote: > >5) Yes, we know that RPM's aren't necessarily compatible across > > distributions. The way that we will address this is by strictly > > limiting what dependencies a RPM can have. The only dependency that > > it can assume the system will have will be something like > > "LSB-1.0". (i.e., no libext2fs, or libc6.0, or other dependencies > > which unfortunately arne't standardized across distributions.) > > For compatibility reasons with Debian dpkg systems using aliens, we > > will also sharply restrict what kind of trigger scripts can be > > included with such RPM's. > > > This is what I was trying to address. Because you can't guarantee what > will be there, you are guaranteeing a minimal subset of out-of-date > libraries. If the LSB had been released 6 months ago, it would require > libc5, but most distros are now glibc2.1 based. If it was released today > it would require Xfree3, but in 6 months distros will HAVE to be Xfree4 > based - new hardware and drivers will force their hand ... (that's > probably a slight exaggeration, but you get my drift).
Every standard, to one extent or another, can be argued as an impediment to innovation. The whole point the LSB is trying to address is to give software developers a target that isn't moving quite as rapidly as the bleeding edge. Does this mean that a standard such as the LSB _can_ have the effect of being a lowest common denominator? Sure. But the related benefit is considered worthwhile to many. An LSB-compliant system need not limit itself to the facilities required by the spec. It must simply guarantee that the facilities are there, possibly alongside more-recent releases. > In other words, as it now stands, the LSB will either act as a major > brake on innovation, or be widely ignored. I suspect it will be the > latter :-( I suspect you misread the mood out there. Demand for the LSB is extremely high; its greatest threat is that the outside community will simply give up waiting for it. The problem is not one of this or that library, it's a real possibility that a substantial number of developers will internally declare the LSB irrelevant, simply target a specific distribution (likely what they see as the 'leader'), and hope that the others can make themselves compatible enough to run it. We already have examples of this, as in "Code Warrior for Red Hat". My greatest fear is that if the LSB goes much longer without any kind of public deliverable, more and more developers will do this. The end result is that "the standard" will evolve into whatever Red Hat puts in a given release, warts and all, and the other distros will likely have to have "red hat compatibility" packages. This would not be far different from the Unix-on-Intel situation of a dozen or so years ago, when SCO was the leader and all the other implementations (Interavtive, Esix, Dell, AT&T) had to have "SCO compatibility packages" to allow them to run SCO binaries. Now, like then, there is heavy demand for *a* standard; all that's at issue is how the standard is defined. Is it a community-wide effort, or does everyone just play catch-up with what Red Hat puts in its next release? Fact is, most of those who want a standard don't really care where it comes from. Many commercial developers are just fine with the idea of deeming Red Hat the 'defacto standard' whether users of other distros like it or not. They'd *prefer* if everyone was in sync with a single neutral spec but their patience is finite. > "The only dependency that it can assume the system will have will be > something like "LSB-1.0". ... which itself would use appropriate dependency mechanisms to ensure that all components required by the spec are installed before the system can respond that "LSB-1.0" is available. The "LSB" pseudo-package could conceivably contain very few files of its own. > While I may not be going about it the right way, the problem I am trying > to address is "I need XFree4 and I need it NOW. Is it there?" That's not how it works. A develper will create software compiled using certain libraries and making certain assumptions about the underlying system. The LSB (pseudo-)package will guarantee to a compliant app that the necessary libraries are available and the assumptions will be valid on the runtime system. > If I need technology that post-dates the most recent LSB, then I'm > stuffed as things currently stand :-( You're not stuffed, you're simply non-compliant. You can't be bleeding edge and standard simultaneously, almost by definition. It's anticipated that the LSB spec will be updated at regular intervals so that an LSB-2.0 might specify newer releases of some components, and others which didn't exist at all in 1.0. > I HAVE to provide rpms, and I HAVE to trust that the distro's default > package manager will "do the right thing". It's all very well putting > "requires LSB 1.2 *and* libs x, y and z" on the box, but firstly how > many people read the documentation, and secondly how many people would > understand what it meant. You could use the package manager's dependency facilities to require them at install time. If I recall correctly, dpkg can even automagically load dependencies if they're not installed. > You may disagree with me, but I don't think a "guaranteed minimum > system" is that important. While non-commercial developers aren't as interested, the marketplace disagrees with you, big time. > What I think should be addressed (and is being completely ignored as > far as I can see) is "what does this system ACTUALLY HAVE". That > latter is certainly the be-all and end-all for bleeding edge gamers, > and probably many others too. LSB is trying to solve a specific problem -- it doesn't look like it can solve yours. But that does not make it useless. Not everyone demands bleeding edge. And you can't be all things to all people. > I'm looking at it from an "experienced user" position. No you're not. You're looking at it from an 'early adopter' position, experience has nothing to do with it. Most Linux users are quite happy using releases half a year old or more providing they work, their security is addressed, and they're supported by an organization larger than someone working out of his basement. > Consider the following scenario - I have a 1Gb program I'm selling. > The most recent LSB is a year old, and has been invalidated by > bleeding-edge distros :-( You can stop the complaint there. An LSB spec, once widely accepted, will never be invalidated. It may be superceded, but it's certainly conceivable that people will make apps against LSB-1.0 long after LSB-3.0 is released. I don't think it's a stretch to suggest that the vast majority of developers don't care about being on the bleeding edge. For every games coder there are a dozen doing databases for dental offices that don't really care about the release of XFree on the target systems. > I want to be able do a 100Mb minimum > install, and it's a pretty safe bet a large proportion of my customers > are lusers. If they're lusers then they won't be using the bleeding edge distros, will they? -- Evan Leibovitch, Brampton, Canada <evan at telly dot org> Anything not worth doing is not worth doing well.
