Re: Package name
Neil Williams wrote:
No, it's the same release. The deb file there is an alienated RPM, and
is not in a state that can go into Debian.
On Friday 20 May 2005 7:31 am, Shachar Shemesh wrote:
I'm trying to package argtable (http://argtable.sf.net). I'm wondering
about the names to give the package.
Is this the next release? There's already a .deb for argtable2 on the website,
although not in Debian itself.
I'm not sure binary incompatible is strictly defined with argtable. See
argtable-2.4-0_i386.deb (precompiled binary, 765KB)
If your package is binary compatible with argtable-2.4.tar.gz then it should
respect the current naming. You only get a chance to move things around at
the next binary incompatible release.
i.e. if your package can be switched for the existing .deb on a user's system
and programs, scripts and processes using the library continue to function
without relinking, then your package should have the same naming. Only if it
breaks something that already runs with 2.4 should it be renamed.
But having a library without a "lib" name breaks and confuses things.
Wouldn't it be better to produce a transition package (i.e. -
argtable-2.4-1 which depends on libargtable2-2.4-1, with a description
saying "you don't need this package unless you are upgrading"?).
Nothing useful. Upstream was calling the end library
"libargtable2.so.4", but not linking the version into the binary at all.
I added that (hence the "4"), but now that I come to think of it,
upstream was probably trying to encode the "2.4" into the name, and did
not mean binary incompatibility by it. If that's the case, the so
should, by right, be called "libargtable.so.2". Problem is, changing it
now will probably break stuff.
The package itself had two major life cycles. As such, the source
library is called "argtable2". As far as so version goes, it has version
What do you get from objdump ?
I had a similar query a week or so ago and the
library SONAME should depend on binary incompatibility, not file package
I only know realized it did. Obviously, both I and upstream will have to
figure the best way out of this.
You say it's had two life cycles, all you need to do now is work
out if your package is going to be binary incompatible with the last one.
Forget the history of it - you can't correct that now and you can't skip an
increment to make it look neat. Whatever SONAME you get from objdump of the
current package, if the new library is binary incompatible with that,
increment the SONAME.
Problem is, the only reason I'm getting anything at all from SONAME is
because I patched the build system. When SONAME has nothing at all, can
that be considered a version "0"? If so, we can set it to "2" and solve
all problems - leave a place if anyone decides to package version 1, and
yet be compatible.
See the archive:
That's what triggered the question to begin with.
I think you'll find it hard telling your linker that you need it. You
won't be able to simply do "-lqofl".
Obviously, I will need to ad a "lib" at the beginning.
I was wondering about that - IS it actually mandatory?
I can have a package name:
leading to a library of
It'll be installed as a library, determined by debian/control, but does the
file actually have to be prefixed lib to make libqof1.so?
In any case, I'm not talking about the actual library file. That already
has the "lib" prefix. I was talking about the package name. Even a
library package that doesn't have a "lib" prefix is somewhat bad. Some
of the tools that do automatic removal of unused libraries take the
package name as an indication to whether it's a library.
As I said above, I'm beginning to question the "-4" for the main package
name as well.
At the moment,
I have this:
source package: argtable2
shared object: libargtable2-4
I thought it would be libartable2-dev?
The site proposes that ArgTable2-x is one set - one introduction, one manpage
and set of examples. Updates and releases that maintain binary compatibility
with other argtable2 releases are within argtable2 and there's no need to
specify the minor or patch version numbers.
Also, if you increment the SONAME, the other versions in the library soname go
to zero, usually.
There are none of those at all, at the moment.
I'll try to resolve this with upstream. If it's a problem on his end, we
may be able to fix that and then the Debian naming will sort itself out.
I suspect we're looking at libargtable3 here, with libargtable3-dev.
Don't confuse the SONAME version with the source package version - the two
don't need to be linked.
You can maintain the existing source version - if that was say 2.5.4 then your
source tarball would be argtable-2.5.4.tar.gz
Should the "dev" be named with the so version? The policy says it
should, but the "2" is really confusing here.
It's the -4 that is confusing. That would go in the package version, not the
In general, I have a suspicion that the "2" was really meant by upstream
to mean what "soversion" means, and so the package should really be
named "libargtable4". This will be WAY too confusing for actual users of
Use objdump and keep the SONAME incremental - don't skip.
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html