[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#54985: debian-policy: handling of shared libraries



On Thu, 13 Jan 2000, Matthew Vernon wrote:

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

The normal situation is, that users have both packages libfoo and
libfoo-dev up to date, which means, that they are the same version and
then both packages include the identical file.

> It's the cases where the shared library isn't a duplicate that are
> important.

But this isn't the normal case for normal users.  I would prefer a
solution which doesn't have drawbacks on normal users.

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

That's the theory.  The reality has shown, that it doesn't always work
in this way...

> debhelper only affects the .deb file, and it should produce correct
> .debs regardless of version.

Take for example the FSSTND -> FHS transition.  When you use the
potato debhelper, the created package will use
/usr/share/{doc,info,man} instead of /usr/{doc,info,man}.

> "mybe some compilers etc." seems like FUD to me.

If you try to create a package for the stable distribution, your
package should not introduce new bugs.  Creating slink packages on a
partly downgraded potato system may not be the optimal way to avoid
the introduction of new bugs...

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

Yes, but I don't think that this is worth duplicating every shared
library over two packages.

[chroot build environment]

> Ugh - so you object to having copies of shared libraries, but
> instead suggest a copy of the entire build environment?

You have to differentiate between Debian maintainers and Debian
users.  The chroot build environment is only needed by some Debian
maintainers, while your proposal duplicates the shared libraries for
every user who installs -dev files.

> Saying "Your proposal is no good because soname-ing doesn't work" is
> a bit silly really;

Okay, let's say it in other words: "Your proposal is not good because
it duplicates identical files in the distribution".

> Note also that the building of slink packages is only one advantage
> of doing things this way.

So you should mention the other advantages, I personally only see the
disadvantages...

Ciao

        Roland

-- 
 * roland@spinnaker.de * http://www.spinnaker.de/ *


Reply to: