Re: RFC

["Robert W. Current, Ph.D." <current@hel-inc.com>]

Jim Knoble wrote:
> Including every dependency isn't the goal nor the intent of LSB.

Then where is the line?  (honestly, not flame bait).

> [*] Yes, X11 libraries *should* be part of the base system.  Rationale:
>     Just as GDI libraries are part of the MS-Windows base system, ISVs
>     expect that minimal level of graphic support to be available as
>     part of the operating system.  Other graphics middleware (e.g.,
>     SVGAlib, MGR, GGI, Berlin, Y, GNUstep/DGS) is optional.

I don't see how this is a "base" issue over a "dependency" issue still.
 
> : Again, no.  It's not a waste of time to say "Look to see if package X is
> : installed by checking /var/pkg/whatever files."  That's the structure that
> : may need defining.  That is something the LSB can do.
> 
> Robert, it doesn't sound to me as if you've ever shipped a commercial
> closed-source application that depends on X11 and numerous other
> graphic (or other) libraries (e.g., libpng, libjpeg, zlib)?

Untrue, but irrelevant.

> You can't
> simply ship an app with dynamic links to e.g. libpng and expect
> whatever version is installed on the system to work.  The LSB spec
> defines what an ISV can expect to find on a system, *without* having to
> resort to some magical (and currently undefined) method of checking
> what's available.

Dependency checking is not magic.

> Should an LSB app have to carry flavors of X11
> libraries around with it in case they're not installed?  No; it makes
> no sense to do so.  X11 libraries have been relatively stable, widely
> used, and widely available for a relatively long period of time.

But this is a case of respec'ing something that's already done by X.

Skipping to the issue:

> ISVs expect it to be there as much as they expect awk or bash or
> or libncurses (which is also, arguably, middleware), if not more so.

Arguably, yes.  And, if it's small middleware, I don't have an issue
with considering it's inclusion.  But, libncurses amounts to what, 4M or
so?  That's definitely borderline, but arguable.  X, I would have to
differ on that point, based on size.
$ pwd
/usr/X11R6/lib
$ du -sh
47M     .

To me, that's a scary base.  It sounds like your only talking about ISVs
who want to do GUI workstation environments if you want to consider
that.  If I had time, I would reference the several dozen articles on
why Linux can do what Windows can, solely because it's scalable, and now
possibly headed towards the embedded market.

But, that's the point.  The base itself should be flexible enough that
it can be built on by any ISV, if Toshiba said tomorrow that all their
new car stereo's were going to run Linux as the OS, so that people could
hack them... I'd stand up and cheer for Toshiba.  It would be a great
day for Linux.

Given, that's a single, maybe not the best example, but the point
remains, there are many people using, and looking at Linux, that would
embrace a standard, but not if it's a huge thing that requires 100M.

(anyone working on something like that?  What about Lineo? anyone know
what it's code looks like size and compliance wise?)

I don't intend on addressing what seems to be the dominate argument
here, that "almost everyone needs X" because I don't believe it.  I
think it's short sighted.  If the LSB requires X, then most ISP's, rack
mount system manufactures, and many "Linux device" companies will be
very far outside of standard compliance.  Take any one of those markets,
and exclude it, and I feel it will be making a mistake.

Consider any major internet site that runs Linux (excite.com, salon.com,
amazon.com, etc..) really should require X on all their servers? 
Obviously no.  Some DB ISVs also will not need X.  I just don't see how
it's absolutely necessary that it be in a "base" set.

By making the LSB include X, your excluding all these people from having
a useful standard to draw from.

> There's no reason at all not to make LSB an enabling technology for
> ISVs, rather than limiting its usefulness to them.

Again, that's just a "let's throw everything including the kitchen sink
in" mentality.  And, there is no reason X can't simply be treated as an
optional layer on the base.

Requirements such as X for some ISV software should be addressed.  But
they should be addressed through a standard package accounting system.

> Including X11 libs
> in the spec is a win-win-win situation for ISVs, users, and
> distribution-makers.  What's the problem?

It's not a win-win-win situation.  It's a win-loose-loose situation. 
Not all ISVs need X, not all linux hardware manufactures need X, not all
distributions use X (Yes, it's true, one of the strengths of Linux is
all the little nitch distributions, don't write them off so fast), and
believe it or not, probably MOST Linux users don't use X (if you
understand that most Linux users don't even know they are using Linux
when they send mail through their ISP, or load a web page from a Linux
server running apache).

So, I still disagree.

begin:vcard 
n:Current;Robert
tel;fax:(732)329-3023
tel;work:(732)329-3090
x-mozilla-html:FALSE
url:http://www.hel-inc.com
org:Hazard Evaluation Laboratories, Inc.;Applications and Installation Engineer
adr:;;1 Deer Park Dr., Suite L;Monmouth Junction;NJ;08852-1921;USA
version:2.1
email;internet:current@hel-inc.com
title:Ph.D.
x-mozilla-cpt:;0
fn:Robert W. Current
end:vcard