On Fri, 11 Apr 2003, Frederick Bruckman wrote:

> I don't recall any significant discussion of this on tech-pkg.

Sometimes a send-pr gets the discussion going. Maybe I should have
submitted to the other PR.

> I don't think you've thought this out very well. What happens
> when you upgrade a package containing shared libraries? It looks
> like the old shared library will end up not being registered to
> any package, and therefore, in the case of a soname change, the

I am not sure what you mean. If the old shared library has a different
filename and was also registered in the +CONTENTS, then it will be
removed. So the problem with not being registered won't matter, because
the file should not exist.

For example, my libcrack is required by PAM. In particular,
/usr/lib/security/pam_cracklib.so uses:
 libcrack.so.2 => /usr/lib/libcrack.so.2 (0x2aab3000)
If that /usr/lib/libcrack.so.2 was missing in a new version of libcrack,
then I hope that version was changed enough and that PAM's DEPENDS for
libcrack was more precise (so not just like libcrack>=2.7 but something
like libcrack-2.*).

I do understand if another package needed that library and now it is
missing, that software will be broken. One idea would be have a dependency
based on an actual filename. Or make sure the dependency for another
package providing the library is very specific, so if the shared library
changes, then it won't allow the upgrade.

I think if the DEPENDS were more precise, then this should not matter,
because pkg_add wouldn't let the upgrade happen.

> preserved +REQUIRED_BY will be a complete lie (not that the
> present "pkg_delete -u" does any better).

Also, I see noted in the code:

                /*
                 * Upgrade step 4/4: Fix pkgs that depend on us to
                 * depend on the new version instead of the old
                 * one by fixing @pkgdep lines in +CONTENTS files.
                 */
                /* TODO */

> I've proposed a trick, where the delta files gets registered to
> a package with a transformed name and the dependencies get shifted
> to that package, and implemented it as a wrapper around the package
> tools. Please see PR pkg/10835, and follow the references therein.

I have briefly looked at pkg_hack. I will look again. Thanks.

   Jeremy C. Reed
   http://bsd.reedmedia.net/