While explaining (in ruglish through PROMT automated translaltion)
details about the meaning of this phrase in the rpm-5.0 press release:

    ... Finally, support for the old RPMv3 (LSB) package format was  
removed ...

a Russian reader was kind enough to attempt to produce LSB packaging
using existing Debian lsb-rpm packages.

(aside) AFAIK the press release is mis-worded. Yes, RPMv3 header+payload
signatures have been removed. rpm-5.0 can still install RPMv3 packages
afaik. I dimly remember checking and succeeding back in October, but
support for RPMv3 packages is rather low on my toto list basically
because there are almost no RPMv3 packages around these days.

The link is at
     http://www.linux.org.ru/view-message.jsp? 
msgid=2391597&lastmod=1199806049755&page=2
but I append the results of the attempt to produce LSB "standard"  
packages below.

AFAIK, the Debian lsb-rpm package is the closest to producing LSB  
"standard"
packaging.

Yet the attempt failed.

Because of the number of implementations (and languages) involved,
I cannot really answer the user's question:
     Is this a Debian bug?

My guess is that it's more likely a LSB "standard" bug, mostly because
of the choice of RPMv3 as a "standard" format way back when. All
existing rpm implementations that I'm aware of (I don't use Debian but
have read through the Debian rpm patches) make producing LSB
"standard" packages very difficult, much harder than it should be.

This message illustrates the need for a better LSB package standard  
and better
LSB tools quite well however, a part of which, documenting the existing
RPMv4 format more explicitly and handing back to LSB, is what the  
<rpm-lsb@rpm5.org>
mailing list will attempt over the next couple of months.

73 de Jeff

======================================================================== 
=============

 > AFAIK, unmodified rpm-4.4.2.1 cannot produce LSB "standard" packages.

 > I know (because I wrote the code) that the original rpm-4.4.2  
release cannot produce LSB "standard" packages.

(replying in English, since I assume that I am talking to the author  
of RPM directly)

OK, should I report a bug to Debian about this? I tried to compile a  
simple package (bison) and to check whether the result is an LSB  
"standard" package using their "lsbpkgchk" tool (installed from their  
RPM, http://ftp.freestandards.org/pub/lsb/test_suites/released-3.1.0/ 
binary/applic... ).

Here is the spec file:

----- 8< -----
Summary: Generates parsers
Name: bison
Version: 2.3
Release: 1
Group: Base
License: GPL
Distribution: LeafOS
Vendor: LeafOS
Packager: LeafOS
URL: http://www.gnu.org/software/bison/
Source0: http://ftp.gnu.org/gnu/bison/bison-%{version}.tar.bz2
BuildRoot: %{_tmppath}/%{name}-root
Requires: lsb = 3.1, lsb-core-ia32 >= 3.0

%description
Bison generates, from a series of rules, a program for analyzing the  
structure
of text files; Bison is a replacement for Yacc (Yet Another Compiler  
Compiler)

%prep
%setup -q

%build
%configure CC=lsbcc3 CXX=lsbc++3
echo '#define YYENABLE_NLS 1' >> config.h
make

%install
rm -rf $RPM_BUILD_ROOT
make DESTDIR=$RPM_BUILD_ROOT install
rm -f $RPM_BUILD_ROOT/usr/share/info/dir

%preun
install-info --delete %{_infodir}/bison.info.gz %{_infodir}/dir

%post
install-info %{_infodir}/bison.info.gz %{_infodir}/dir

%files
%defattr(-,root,root)
/*
%doc AUTHORS COPYING ChangeLog NEWS README THANKS TODO

%clean
rm -rf $RPM_BUILD_ROOT
----- 8< -----

Here is the report:

----- 8< -----
checkRpmIdxHEADERSIGNATURES() Not yet checking contents
checkRpmIdxHEADERSIGNATURES() offset ffffffb0
checkRpmIdxHEADERSIGNATURES() data at b7da40b4
checkRpmIdxSHA1() Not yet checking SHA1 contents
SIGTAG_MD5 calculated value doesn't match expected value
checkRpmIdxHEADERIMMUTABLE() Not yet checking contents
Post-install program not checked
Pre-uninstall program not checked
checkRpmIdxPROVIDENAME() type=8 offset=89c count=1 bison
Unexpected REQUIREFLAGS bit: 4000
Provide Flag not checked: 8
Optflags not checked: -O2 -g -march=i486
Error: checkRpmIdx() unexpected Index tag=1140 type=4 offset=d00  
count=21
Error: checkRpmIdx() unexpected Index tag=1141 type=4 offset=d84  
count=21
Error: checkRpmIdx() unexpected Index tag=1142 type=8 offset=e08 count=7
Error: checkRpmIdx() unexpected Index tag=1143 type=4 offset=eec  
count=21
Error: checkRpmIdx() unexpected Index tag=1144 type=4 offset=f70  
count=21
Error: checkRpmIdx() unexpected Index tag=1145 type=4 offset=ff4 count=1
Error: checkRpmIdx() unexpected Index tag=1147 type=8 offset=ff8  
count=21
Warning: checkRpmIdx() Deprecated Index RPMTAG_RHNPLATFORM found
checkRpmArchiveFilename: file usr not FHS compliant
checkRpmArchiveFilename: file usr/bin not FHS compliant
(and a lot more of "not FHS compliant")
----- 8< -----

What's worse, when I tried to check their own RPM file with this  
utility, it found errors (albeit different). So, I think that indeed,  
the most clever thing that one can do with LSB is to ignore that  
standard, because their sample implementation and tools can't pass  
their own testsuite.