Re: RFS: fmodapi4.26
On Wed, Jan 12, 2011 at 6:05 AM, Johey Shmit <joheyshmit@yahoo.com> wrote:
> I took zlib as a guideline and named it after the upstream name.
>
> Because version '4.26', '4.27', etc. are not binary compatible I
> added the '4.26' to the package name. That way different versions
> should be installable in parallel.
zlib is an interesting corner case: the general rule is found:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#naminglibpkg
The policy documents how to name library packages.
"lib[libraryname][SONAME-version-number]" like "libc6" for
/lib/libc.so.6
You're free to name the source package fmodapi, but the binary package
should be something like libfmodapi (because that is from your
library's filename). I know your package lacks a SONAME, but you can
add one like the enet package does. their binary makes a library with
the SONAME libenet.so.0debian1, so their binary package is
libenet0debian1 and their source package name is enet.
In general, you can use the following to get the package name:
objdump -p /path/to/libfoo-bar.so.1.2.3 | \
sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' | \
sed -e's/\([0-9]\)\.so\./\1-/; s/\.so\.//'
Your package should probably be something like:
libfmodapi-4.26
and your -dev package should be
libfmodapi-dev
> This is my lintian output:
>
> lintian --pedantic -I ../fmodapi4.26_4.26.30-2_amd64.changes
> W: fmodapi4.26 source: out-of-date-standards-version 3.8.4 (current is 3.9.1)
> E: fmodapi4.26: sharedobject-in-library-directory-missing-soname
> usr/lib/libfmodex64-4.26.so.26.30
> E: fmodapi4.26: sharedobject-in-library-directory-missing-soname
> usr/lib/libfmodexp64-4.26.so.26.30
>
> I do only have a Ubuntu 10.10 development environment at the moment,
> so I'm stuck with the older standards version.
You can use a VM (e.g. virtualbox-ose) to get a deiban environment.
You can use a higher standards version in ubuntu 10.10, just change
debian/control to have version 3.9.1. Standards version just indicates
the policy you used when making your package - it doesn't do anything
to how the package is built.
>
> The SONAME-Error is the one that I can't do anything about. It's been
> build without SONAME. So any software linked to it will link to
> libfmodex64-4.26.so
> without any suffix. I made a comment about that in README.Debian.
You also have to override lintian errors:
http://lintian.debian.org/manual/ch2.html
I don't think packages are accepted by ftp-masters that have lintian
errors that are not overridden (and there has to be a good reason to
override them). I think you should give you packages a SONAME:
libfmodex-4.26.so.0debian1, name your package accordingly, and thus
remove the warning without overriding lintian. See the enet package on
how to do that.
If lintian gives you an error, you really have to find a way to fix it
- I don't think errors should be overridden.
I'm sorry that this package is difficult: libraries in general have
more policy requirements than applications, and this one in particular
is difficult since it has an unusual naming convention (no soname and
names the binaries after the architecture that built them)
~Scott
Reply to: