Re: Versioned Symbols

[Junichi Uekawa <dancer@netfort.gr.jp>]

> > 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
      unique.


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



regards,
	junichi