Re: Versioned Symbols
> > Consider libpng2/3 problem, and see if it possible to
> > still possible to cause problem while following libpkg-guide.
> Yes, and I think it's frightening that you advocate staticly linking
> things in your libpkg-guide and the fact that you even wrote one while
> apparently not entirely understanding the issues involved...
Hmmm? I don't
static linking is documented as why X is statically linked.
I advocate use of proper soname versioning, and
precise -dev package naming, and -dev package dependencies.
You are reading something wrong.
As a temporary measure such fast moving libraries can be built as .a
libraries and statically linked to. This ensures that binaries contain
the object files they were compiled against. Be careful though, while
this removes the need of an ever increasing SONAME version number,
doing this can cause
problems later if these static libraries are used in shared objects of other
packages. And also, this does not solve everything.
Library packages are constantly evolving for a reason.
Using statically linked libraries open up a can of worms.
Even if upstream does not come up with a shread library,
it might be better to use -release flag to add a Debian
specific version string, like debian.20020512.
Constructing the version number including the string
debian, and the date should make the version number
I don't advocate it.
Did you *really* read the libpkg-guide ?
It's been edited over the last year, and I consider it to be
pretty good documentation, that if some parts of it entered policy
we could avoid situations like libssl0.9.6