Mail Archives: cygwin/2002/05/20/10:44:43
LSB is not just about binary compatibility; it's also about
file hierarchies, configuration mechanisms, and utilities
for installation and maintenance.
I'd like to bring attention to standardisation of XML
resources.
Some packages are more or less architecture-independent,
e.g., TeX/LaTeX formats and SGML/XML DTDs. Keeping in line
with LSB minimizes the porting effort. While there's an
established way to handle TeX resources, things are not
quite sorted out for SGML/XML. A proposed standard for
installation and maintenance of SGML resources [1] didn't
make it into the LSB 1.1. The standardisation effort was
recently restarted [2].
XML and data- and transaction-oriented applications must
now be taken into consideration; the original proposal
was strictly SGML-and-document oriented (and focused
rather narrowly on DocBook). This has been discussed and
is, to the best of my knowledge, acknowledged.
Just as XML is not just about documents, it's also rather
promiscuous about platforms. Java is very important in
this respect, but Cygwin might also play a role here.
Cygwin seems to be popular with some of the XML hot-shots
when they for some reason or another have to work on
Win32 boxes.
I'm afraid I can't offer much more -- except that I think
we should continue discussing such matters here and on
the cygwin-apps list.
kind regards
Peter Ring
[1] http://people.debian.org/~mrj/lsb-sgmlspec_cvs20020308/index.html
[2] https://lists.dulug.duke.edu/mailman/listinfo/lsb-xml-sgml
-----Original Message-----
From: Charles Wilson [mailto:cwilson AT ece DOT gatech DOT edu]
Sent: 17. maj 2002 18:49
To: Michael Smith
Cc: cygwin AT cygwin DOT com
Subject: Re: name: GNU/Cygwin system
<snip />
To tell you the truth, I don't see there being much hope -- or reason
for -- the LSB to take cygwin into account. Thanks to various
microsoftisms, we're too weird. Non-ELF shared libraries split into
"runtime" and "linktime" pieces. Runtime loader works completely
differently than ld.so, so library versioning is handled completely
differently. Then, we have two different windowing systems..."native"
and "X" which must coexist. The best I can see is for cygwin to take
what LSB does, and try to follow it as best we can while making
allowances for the uniqueness of the platform. We are the best ones to
judge where those allowances must be made -- not them. While the linux
distributors can (eventually) reach a compromise position that all linux
distributions can follow, there is no "compromise" here -- they'd have
to put "special case exceptions" in their document specifically for
cygwin. But there's no need to uglify the LSB with all that:
What is the main purpose of the LSB? Binary interoperability, so that
third party software vendors can ship ONE package that is guaranteed to
work on every LSB-compliant Linux platform. Doesn't really apply to
cygwin...and oh, yeah, how does RMS feel about making life easier for
proprietary (possibly closed source) vendors? Would he want the name
GNU associated with THAT?
<snip />
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -