Debian Bug report logs - #398874
RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Cc: debian-lsb@lists.debian.org

Subject: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

Date: Wed, 15 Nov 2006 21:27:58 -0800

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
taggart@debian.org

Message #10 received at 398874@bugs.debian.org (full text, mbox, reply):

From: "Ian Murdock" <imurdock@imurdock.com>

To: "Matt Taggart" <taggart@debian.org>

Cc: 398874@bugs.debian.org, debian-lsb@lists.debian.org

Subject: Re: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

Date: Thu, 16 Nov 2006 06:00:38 -0500

On 11/16/06, Matt Taggart <taggart@debian.org> 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
> targeting LSB 2 or 3.

LSB 2 is obsolete too, so I would recommend removing lsb-appchk2 as well.
All users should be targeting LSB 3.

-ian
-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige

Message #15 received at 398874@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: "Ian Murdock" <imurdock@imurdock.com>

Cc: "Matt Taggart" <taggart@debian.org>, 398874@bugs.debian.org, debian-lsb@lists.debian.org

Subject: Re: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

Date: Thu, 16 Nov 2006 03:23:39 -0800

"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 releases of distros that only have LSB 2
  compliance (or as a common denominator when targeting multiple)
* for comparison with LSB 3 when evaluating apps
* to be able to test (historic) claims of LSB 2 compliance (similar
    argument to putting things in "oldlibs")

I think maybe the policy should be to support N and N-1 for these tools. For 
LSB runtime support we may want to support as many versions as is easily 
possible. I think LSB 1.x stuff should still work, although I don't know if 
anyone has run the 1.x tests in a really long time.

-- 
Matt Taggart
taggart@debian.org

Message #20 received at 398874@bugs.debian.org (full text, mbox, reply):

From: "Ian Murdock" <imurdock@imurdock.com>

To: "Matt Taggart" <taggart@debian.org>

Cc: 398874@bugs.debian.org, debian-lsb@lists.debian.org

Subject: Re: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

Date: Thu, 16 Nov 2006 06:34:06 -0500

On 11/16/06, Matt Taggart <taggart@debian.org> 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 test LSB 2 compliance:
>
> * for use when targeting older releases of distros that only have LSB 2
>   compliance (or as a common denominator when targeting multiple)
> * for comparison with LSB 3 when evaluating apps
> * to be able to test (historic) claims of LSB 2 compliance (similar
>     argument to putting things in "oldlibs")
>
> I think maybe the policy should be to support N and N-1 for these tools. For
> LSB runtime support we may want to support as many versions as is easily
> possible. I think LSB 1.x stuff should still work, although I don't know if
> anyone has run the 1.x tests in a really long time.

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. Furthermore, the rest (Linpus, Mandriva, Sun Wah) are about to LSB
3.1 certify new versions. That, and the fact that LSB 2 is not compatible
with LSB 3 (whereas LSB 3 and higher will be backward
compatible), leads us to strongly discourage anyone from targeting LSB 2.

-ian
-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige

Message #25 received at 398874@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: "Ian Murdock" <imurdock@imurdock.com>

Cc: "Matt Taggart" <taggart@debian.org>, 398874@bugs.debian.org, debian-lsb@lists.debian.org

Subject: Re: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

Date: Thu, 16 Nov 2006 04:19:41 -0800

"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 RHEL 3 when I wrote that, but checking the 
certifications at

http://www.freestandards.org/cert/certified.php

it looks like we'd have to support back to LSB 1.3 in order to cover that :(
There are a couple of 2.0 certs in there, but since 2.0 was so short lived not 
too many I guess.

> 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.

> That, and the fact that LSB 2 is not compatible with LSB 3

They had different ABIs but a system could support both at the same time right?
I thought the whole point of a major version of the LSB is so you could break 
the ABIs when needed (mainly when upstream does) and a runtime system could 
support both ABIs at the same time by delivering both sets of libs. This would 
allow application developers and users time to gradually transition. This is 
particularly true in big Linux shops with bunches of applications, all their 
apps won't be on the new version of the LSB right away. If people try hard and 
there are good roadmaps, hopefully everyone moves around the same time, but 
it's impossible to get _everything_ to line up perfectly, there are just too 
many variables.

Maybe you mean LSB 2 applications are not compatible with LSB 3 runtimes (we 
know that to be true with libstdc++ in particular, and probably other cases).

If the ABIs _are_ compatible going forward then they can just be minor LSB 
versions right? Wouldn't that imply that LSB major revisions are _only_ for 
ABI breaks? Unless maybe major revisions are also for marketing reasons?

If upstreams are good about versioning their libraries, you could probably 
transition from one version to the next by just adding the new versioned 
library (I can't remember how the LSB feels about that, maybe only at major 
versions?). To deprecate the old version you'd need an LSB major version I 
think.

> (whereas LSB 3 and higher will be backward compatible),

I don't understand what this means. Are you saying newer LSB applications will 
be able to run on older LSB runtimes? If so how would that work?

> leads us to strongly discourage anyone from targeting LSB 2.

Sure. But I don't want to pull the rug out on the older versions yet either. 
LSB 1.3 is old enough that I felt OK asking for the 1.x lsbappchk to be 
removed from the archive, but IMO 2.0 isn't quite old enough yet.

-- 
Matt Taggart
taggart@debian.org

Message #30 received at 398874@bugs.debian.org (full text, mbox, reply):

From: "Ian Murdock" <imurdock@imurdock.com>

To: "Matt Taggart" <taggart@debian.org>

Cc: 398874@bugs.debian.org, debian-lsb@lists.debian.org

Subject: Re: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

Date: Thu, 16 Nov 2006 08:58:56 -0500

On 11/16/06, Matt Taggart <taggart@debian.org> 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 work on 3.1.

> > That, and the fact that LSB 2 is not compatible with LSB 3
>
> They had different ABIs but a system could support both at the same time right?
> I thought the whole point of a major version of the LSB is so you could break
> the ABIs when needed (mainly when upstream does) and a runtime system could
> support both ABIs at the same time by delivering both sets of libs. This would
> allow application developers and users time to gradually transition. This is
> particularly true in big Linux shops with bunches of applications, all their
> apps won't be on the new version of the LSB right away. If people try hard and
> there are good roadmaps, hopefully everyone moves around the same time, but
> it's impossible to get _everything_ to line up perfectly, there are just too
> many variables.
>
> Maybe you mean LSB 2 applications are not compatible with LSB 3 runtimes (we
> know that to be true with libstdc++ in particular, and probably other cases).
>
> If the ABIs _are_ compatible going forward then they can just be minor LSB
> versions right? Wouldn't that imply that LSB major revisions are _only_ for
> ABI breaks? Unless maybe major revisions are also for marketing reasons?
>
> If upstreams are good about versioning their libraries, you could probably
> transition from one version to the next by just adding the new versioned
> library (I can't remember how the LSB feels about that, maybe only at major
> versions?). To deprecate the old version you'd need an LSB major version I
> think.
>
> > (whereas LSB 3 and higher will be backward compatible),
>
> I don't understand what this means. Are you saying newer LSB applications will
> be able to run on older LSB runtimes? If so how would that work?

http://www.freestandards.org/en/LSB_Roadmap

http://www.freestandards.org/en/Application_Compatibility

-ian
-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige

Message #35 received at 398874@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <matt@lackof.org>

To: "Ian Murdock" <imurdock@imurdock.com>

Cc: "Matt Taggart" <taggart@debian.org>, 398874@bugs.debian.org, debian-lsb@lists.debian.org

Subject: Re: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

Date: Thu, 16 Nov 2006 14:01:09 -0800

"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
> 
> http://www.freestandards.org/en/Application_Compatibility

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 of 
the LSB, that's not new with 3.0. I think previous versions of the LSB have 
met that goal too, unless I'm mistaken (Mats can you confirm?).

-- 
Matt Taggart
taggart@debian.org

Message #40 received at 398874@bugs.debian.org (full text, mbox, reply):

From: "Ian Murdock" <imurdock@imurdock.com>

To: "Matt Taggart" <matt@lackof.org>

Cc: "Matt Taggart" <taggart@debian.org>, 398874@bugs.debian.org, debian-lsb@lists.debian.org

Subject: Re: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

Date: Thu, 16 Nov 2006 17:35:58 -0500

On 11/16/06, Matt Taggart <matt@lackof.org> 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?
> >
> > http://www.freestandards.org/en/LSB_Roadmap
> >
> > http://www.freestandards.org/en/Application_Compatibility
>
> 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 of
> the LSB, that's not new with 3.0. I think previous versions of the LSB have
> met that goal too, unless I'm mistaken (Mats can you confirm?).

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!

-ian
-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige

Message #45 received at 398874@bugs.debian.org (full text, mbox, reply):

From: "Ian Murdock" <imurdock@imurdock.com>

To: "Matt Taggart" <matt@lackof.org>

Cc: "Matt Taggart" <taggart@debian.org>, 398874@bugs.debian.org, debian-lsb@lists.debian.org, "Mats Wichmann" <mats.d.wichmann@intel.com>

Subject: Re: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

Date: Thu, 16 Nov 2006 17:38:19 -0500

On 11/16/06, Matt Taggart <matt@lackof.org> 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?
> >
> > http://www.freestandards.org/en/LSB_Roadmap
> >
> > http://www.freestandards.org/en/Application_Compatibility
>
> 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 of
> the LSB, that's not new with 3.0. I think previous versions of the LSB have
> met that goal too, unless I'm mistaken (Mats can you confirm?).

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.

-ian
-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige

Message #50 received at 398874@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: Matt Taggart <taggart@debian.org>

Cc: "Ian Murdock" <imurdock@imurdock.com>, 398874@bugs.debian.org

Subject: Re: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

Date: Thu, 16 Nov 2006 14:52:17 -0800

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 mistaken (Mats can you confirm?).

Hmm, maybe I should have had more coffee before posting....

I had Backwards and Forwards swapped

http://en.wikipedia.org/wiki/Backward_compatibility
http://en.wikipedia.org/wiki/Forward_compatibility

Previous versions of the LSB have been backwards compatible within a major 
version and when possible across major versions for libraries of the same 
SONAME version. But if the ABI needed to break for the same SONAME version, it 
was done at a major version.

What will future versions of the LSB do when an upstream breaks an ABI but 
doesn't roll the SONAME version? Will the LSB fork the ABI or follow upstream?

-- 
Matt Taggart
taggart@debian.org

Message #55 received at 398874@bugs.debian.org (full text, mbox, reply):

From: "Wichmann, Mats D" <mats.d.wichmann@intel.com>

To: "Ian Murdock" <imurdock@imurdock.com>, "Matt Taggart" <matt@lackof.org>

Cc: "Matt Taggart" <taggart@debian.org>, <398874@bugs.debian.org>, <debian-lsb@lists.debian.org>

Subject: RE: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

Date: Thu, 16 Nov 2006 14:51:57 -0800

>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 complete swap-out, with a new
version number. The small number of libc symbols 
removed are almost still in every glibc version.
Someone could certainly implement a 3.0 system
completely/only to the specification and then they 
would not have the missing 2.0 symbols, but this is 
not happening in practice.

However, the real issue is that LSBs of the past do 
not *require* a distribution conforming to a certain
version to support any other version's applications,
so there's no *promise* of the backwards compatibility.
Technologically, with the addition of the older C++
library, and the required LSB linker, an LSB 3 system
ought to run LSB 2 apps.  The model in the past was
to leave this possible, but at the discretion of the
distribution provider: if they wished to support
multiple LSB versions they could do so. As an example, 
SuSE have certified systems to both 2.0 and 3.0 
simultaneously. Thus, on any arbitrary system certified
to 3.0, you have no promise of running 2.0 apps unless
that distribution also has completed the 2.0 certification,
or less formally, provided a "2.0 compatibility kit" -
which is probably not too far different from how they
handle old-version support for their own distributions.

Message #60 received at 398874@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: "Ian Murdock" <imurdock@imurdock.com>

Cc: "Matt Taggart" <taggart@debian.org>, 398874@bugs.debian.org, debian-lsb@lists.debian.org

Subject: Re: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

Date: Thu, 16 Nov 2006 15:31:53 -0800

"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 of the 3 other people I asked I got 3 
additional opinions all different from my view and all different from 
wikipedia....

*sigh* At least we agree on the case we're referring to.

-- 
Matt Taggart
taggart@debian.org

Message #65 received at 398874-close@bugs.debian.org (full text, mbox, reply):

From: Debian Archive Maintenance <ftpmaster@ftp-master.debian.org>

To: 398874-close@bugs.debian.org

Cc: lsbappchk@packages.debian.org, lsbappchk@packages.qa.debian.org

Subject: Bug#398874: fixed

Date: Mon, 20 Nov 2006 07:24:08 -0800

We believe that the bug you reported is now fixed; the following
package(s) have been removed from unstable:

 lsbappchk |    1.3.4-1 | source, amd64, i386, ia64, powerpc, s390

Note that the package(s) have simply been removed from the tag
database and may (or may not) still be in the pool; this is not a bug.
The package(s) will be physically removed automatically when no suite
references them (and in the case of source, when no binary references
it).  Please also remember that the changes have been done on the
master archive (ftp-master.debian.org) and will not propagate to any
mirrors (ftp.debian.org included) until the next cron.daily run at the
earliest.

Packages are never removed from testing by hand.  Testing tracks
unstable and will automatically remove packages which were removed
from unstable when removing them from testing causes no dependency
problems.

Bugs which have been reported against this package are not automatically
removed from the Bug Tracking System.  Please check all open bugs and
close them or re-assign them to another package if the removed package
was superseded by another one.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 398874@bugs.debian.org.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@debian.org.

Debian distribution maintenance software
pp.
Anthony Towns (the ftpmaster behind the curtain)

Send a report that this bug log contains spam.