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


På 2000-Mar-15 klokka 16:27:25 -0500 skrivet Robert W. Current Jr. Ph.D.:

: No ISV should feel that "every dependacy has been included in the LSB"
: The LSB should be a base for self contained binaries, maybe, but not an
: all enclusive list of common dependancies.
: Dependancy handling is a matter of package installation accounting.  This
: may be outlined by the LSB.... /var/pkg?  Dunno, but it's an accounting
: issue.

Including every dependency isn't the goal nor the intent of LSB.
Including X11 libraries in the spec is the intent, even if it's simply
a reference to a particular spec generated by XFree86 or someone else,
for the simple reason application vendors need to know what environment
they can expect to see on an LSB-compliant system and what software
components the apps have to carry around with them.  The spec is
relatively clear on this: X11 libraries are included in the base
system[*]; apps can link dynamically with them.  PNG libraries aren't;
fully LSB-compliant apps have to link statically with them, or carry
around a private shared object.

[*] 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.

: 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)?  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.  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.  GNOME
libraries, for example, haven't been.  X11 libs are in the spec; GNOME
libs aren't.  It's not as complicated as you seem to make it sound.

: Making X a base application because it's "a common depencancy" is not
: going to solve the problem any more than simply laying out a standard for
: tracking packages.

I beg to differ, for the reasons i suggest above.

: Adding X just adds to the bloat of the base.  It opens the door too much
: for "Well, almost everything now uses KDE or GNOME, that should be base
: too" etc etc etc... Don't go there.  Just say no.  This is your brain..
: This is your brain on X... ... uh.. wait... 

I beg to differ again.  If there comes a time when KDE or GNOME (or
both, or their offspring or successor) become widely used, stable, and
widely available, they have in fact turned into the prosaic ``de facto
standard'', which should be defined.  It's conceivable that, if the
right replacement for X11 comes along and does the right thing, that a
future LSB spec will deprecate X11 and add the replacement.

: I still don't see why X should be "base" because it's commonly used,
: when at best it can be discribed as "middleware."

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.
There's no reason at all not to make LSB an enabling technology for
ISVs, rather than limiting its usefulness to them.  Including X11 libs
in the spec is a win-win-win situation for ISVs, users, and
distribution-makers.  What's the problem?

jim knoble

Reply to: