Re: Package name
Neil Williams wrote:
On Friday 20 May 2005 7:31 am, Shachar Shemesh wrote:
Hi list,
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.
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.
argtable-2.4-0_i386.deb (precompiled binary, 765KB)
http://argtable.sourceforge.net/
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'm not sure binary incompatible is strictly defined with argtable. See
below.
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"?).
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
4.
What do you get from objdump ?
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.
I had a similar query a week or so ago and the
library SONAME should depend on binary incompatibility, not file package
versions.
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:
http://lists.debian.org/debian-mentors/2005/05/msg00057.html
That's what triggered the question to begin with.
Obviously, I will need to ad a "lib" at the beginning.
I was wondering about that - IS it actually mandatory?
I've got:
qof-0.5.2.tar.gz
I can have a package name:
qof1
leading to a library of
qof1.so
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?
I think you'll find it hard telling your linker that you need it. You
won't be able to simply do "-lqofl".
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.
At the moment,
I have this:
source package: argtable2
shared object: libargtable2-4
devel: libargtable2-4-dev
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.
As I said above, I'm beginning to question the "-4" for the main package
name as well.
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 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
package name.
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
argtable, however.
Use objdump and keep the SONAME incremental - don't skip.
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.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
Reply to: