On 11/16/06, Matt Taggart [EMAIL PROTECTED] wrote:
Package: ftp.debian.org
Severity: normal
The package lsbappchk has been superseded by lsb-appchk2 and
lsb-appchk3. This package was for the 1.3 version of the LSB standard
which is now obsolete so it can be removed. All users should now be
Ian Murdock writes...
LSB 2 is obsolete too, so I would recommend removing lsb-appchk2 as well.
All users should be targeting LSB 3.
You are right that the v3 tools should be the recommended ones.
But I can still see a need to be able to test LSB 2 compliance:
* for use when targeting older
On 11/16/06, Matt Taggart [EMAIL PROTECTED] wrote:
Ian Murdock writes...
LSB 2 is obsolete too, so I would recommend removing lsb-appchk2 as well.
All users should be targeting LSB 3.
You are right that the v3 tools should be the recommended ones.
But I can still see a need to be able to
Ian Murdock writes...
That's fine, but the only distro I see anyone targeting anymore in the
list of LSB 2.0 certified distros is SLES 9, and that's LSB 3.0 certified
as well.
I was thinking of application developers that might want to build applications
that would work on things as old as
On 11/16/06, Matt Taggart [EMAIL PROTECTED] wrote:
Furthermore, the rest (Linpus, Mandriva, Sun Wah) are about to LSB
3.1 certify new versions.
Yeah, application developers who only care to support the very latest versions
of distros can just target 3.1.
They can target LSB 3.0 as well and
Ian Murdock writes...
(whereas LSB 3 and higher will be backward compatible),
I don't understand what this means. Are you saying newer LSB applications w
ill
be able to run on older LSB runtimes? If so how would that work?
http://www.freestandards.org/en/LSB_Roadmap
On 11/16/06, Matt Taggart [EMAIL PROTECTED] wrote:
Ian Murdock writes...
(whereas LSB 3 and higher will be backward compatible),
I don't understand what this means. Are you saying newer LSB applications w
ill
be able to run on older LSB runtimes? If so how would that work?
On 11/16/06, Matt Taggart [EMAIL PROTECTED] wrote:
Ian Murdock writes...
(whereas LSB 3 and higher will be backward compatible),
I don't understand what this means. Are you saying newer LSB applications w
ill
be able to run on older LSB runtimes? If so how would that work?
Matt Taggart writes...
Ah I see the confusion, you are talking about forwards compatibility (not
backwards, that would be the case I described). That has always been a goal o
f
the LSB, that's not new with 3.0. I think previous versions of the LSB have
met that goal too, unless I'm
Mats can confirm, but it's my understanding that LSB 3.0 is
not backward compatible with LSB 2.0, i.e., LSB 2 apps won't
necessarily run on LSB 3 runtimes because some symbols were
removed between LSB 2 and LSB 3.
There are some minor changes, and one very major one:
the C++ library was a
Ian Murdock writes...
Oh yeah, I forgot that HP reverses backward and forward compatibility
from what I'm used to.. Note that Wikipedia agrees with my definition,
so it must be true!
I took a small poll at HP and determined that I was the only one that held
that backwards view :) Although
Package: ftp.debian.org
Severity: normal
The package lsbappchk has been superseded by lsb-appchk2 and
lsb-appchk3. This package was for the 1.3 version of the LSB standard
which is now obsolete so it can be removed. All users should now be
targeting LSB 2 or 3.
Thanks,
--
Matt Taggart
[EMAIL
12 matches
Mail list logo
