Bug#54985: debian-policy: handling of shared libraries
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
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.
> 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.
> When slink was being burned onto CDs for other architectures, there
> were some very irate bug reports against trn, since it depended on
> libraries that were not available in slink; the bug was reported by
> the m68k people, all of whose build daemons were using potato
> libraries. It took quite a lot of time and effort to find a
> slink-only machine that trn could be built on.
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.
- Instead of this, it would be a better idea to keep one machine (the
Debian project has access to a quite big pool of machines now) of
every architecture on the state of the last stable distribution.
This machine would allow us to compile security fixes and the like
without big problems on the stable distribution.
- 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...
> This policy change solves such problems
No, it only tries to work around the problems. It doesn't solve them
but opens new problems.
> 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.
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.
> What maintainers do about which version of the shared object to
> provide is up to them. Some library authors always ensure
> backwards-compatibility with their libraries, so the situation is
> simplified; in other cases it may be advisable to make the
> $distribution -dev package build binaries that can be run on the
> $distribution-1 runtimes. In good libraries with forward-compatible
> APIs, then the -dev .so can clearly be the same as the runtime
> one. It should be noted that installing upgraded runtimes should be
> harmless.
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.
I don't like your proposal, because I don't think, that it solves the
problem (alternatives are mentioned above) while it causes new problems.
Ciao
Roland
--
* roland@spinnaker.de * http://www.spinnaker.de/ *
Reply to: