Bug#54985: debian-policy: handling of shared libraries
Roland Rosenfeld writes:
> On Thu, 13 Jan 2000, Matthew Vernon wrote:
>
> > Summary: -dev packages should actually provide a real libfoo.so,
> > rather than a symlink to the shared object provided by the runtime
> > package.
>
> Which means, that everybody, who installs a -dev package, has two
> identical files on his machine. I don't like this implication, it's
Not necessarily - they certainly may be identical, but not necessarily.
> ugly enough, that we have a shared and a static variant of most
> libraries installed, where the static variant is used very seldom, but
> this static library has a special sense, while duplicating the shared
> library doesn't make much sense for me.
It's the cases where the shared library isn't a duplicate that are important.
> > The object of this proposal is to divorce the version of the -dev
> > package from the version of the runtime.
>
> Are you really sure, that this is a good idea? I don't think so.
Yes;
> I know these problems, but I don't think that downgrading some
> lib*-dev packages is the correct solution for this problem, because:
> - If you only downgrade some lib*-dev packages, you cannot really be
> sure, that the created package is really compatible to the old
> distribution. In addition you also have to downgrade debhelper,
> maybe some compilers etc. You won't get a real "slink" environment
> with this, so you cannot be sure, that the created binary works on
> slink machines.
That's incorrect. If you build a package using the slink development
libraries, then that binary will run on systems running both the slink
and potato runtimes (if this is not a case, then upstream should have
made a soname change, so this will be apparent). debhelper only
affects the .deb file, and it should produce correct .debs regardless
of version. "mybe some compilers etc." seems like FUD to me.
OK, so you don't get a real "slink" environment, but bugs
notwithstanding, you will get a binary that will run on a slink machine.
> - If we don't have enough machines available for the above idea, it
> would be nice, if someone would create packages named
> slink-buildenv, potato-buildenv and so on, which create a changeroot
> environment, which gets all base packages. Then you can enter this
> chroot environment and do an "apt-get build-essentials" as well as
> getting all build-dependencies (is there some public available tool,
> which can automate this?) and you can build slink packages on your
> potato system (or vice versa). This technique also gives the
> developer the chance to test his Build-Dependencies, because in the
> chroot environment you will notice, if some packages are missing...
Ugh - so you object to having copies of shared libraries, but instead
suggest a copy of the entire build environment?
> > This policy change solves such problems
>
> No, it only tries to work around the problems. It doesn't solve them
> but opens new problems.
It clearly does solve such problems - you've simply tried FUDing the
suggestion, or don't quite understand how shared library versions
work. I don't see any "new problems" opened by it either.
> > simply install the slink -dev package(s), and away you go.
>
> And what about debhelper? What about small library packages, which
> bundle library and include files in one package? And there may be
> other similar problems, which I don't see at the moment.
Library packages which contain runtime and include files in one
package are in violation of policy anyway (section 4.3). Debhelper is
a red herring - it should produce correct .debs regardless, shouldn't
it? In the end all it's doing is correctly arranging debian/tmp and
then calling dpkg-deb --build.
> IMHO there is exactly one way to create working slink packages:
> compile them in a slink environment (either by installing slink on the
> machine or by installing slink in a chroot environment). All other
> work arounds will cause more problems than they solve.
This is mistaken (reasons above).
> That's the theory and now have a look what happened when upgrading
> from glibc2.0 to glibc2.1. Theory says, that all programs linked
> against 2.0 will keep working with 2.1, but in reality some programs
> (like netscape and jdk) failed.
This is due to bugs in the code of those programs (netscape had a
similar problem between 5.2.18 and 5.3.12 since the latter enforced
malloc() policies more rigorously). Saying "Your proposal is no good
because soname-ing doesn't work" is a bit silly really; the concept of
sonames is a good one - I'm suggesting we use it to our advantage, and
sonames work usually (I'm generally inclined to think that it's a
fault of bad code not the libraries when they don't work), since there
are a well-defined set of changes to a library that make it either
backward-compatible or not, and authors of libraries are aware of
these, and make soname changes or not as appropriate.
Note also that the building of slink packages is only one advantage of
doing things this way.
Matthew
--
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org
Reply to: