On 26 Aug 2002, Rene Hexel wrote:

> On Mon, 2002-08-26 at 12:11, Frederick Bruckman wrote:
>
> > If you'd used "pkg_hack -d", that shared library would still be on the
> > system, and owned by "pango-SO-1.0.4".
>
>   But I don't want that when I simply want to get rid of a package (I'm
> *not* attempting an upgrade here)!  Neither do I want any dependent
> packages, such as gtk2+ to keep lying around in a defunct state.
>
>   I want to be able to clean up any packages using "pkg_delete" without
> leaving the package system in an inconsistent state.

What you want to do then, is "pkg_delete -r pango pango-SO-\*".

> > Your saying, it'll work if you only upgrade pango-1.0.3 completely
> > before touching pango-1.0.4, and the dependencies should guarantee
> > that that's done, but that's the wrong approach.
>
>   Why is that the wrong approach?  That's the way the package system
> works now, and I don't see any reason to require a major change if the
> same can be achieved with a more consistent (relatively minor) change.

Pretend like it wasn't a hack, that "pkg_delete" has been changed to
enforce saving shared libraries on "pkg_delete" -- now why would
anyone want to use the old package tools on their new-style database?

>   Once I do a "pkg_hack -a pango-1.0.4", what I think should be done is
> to add an additional dependency of the (already in-place) pango-SO-1.0.3
> on the new pango-1.0.4 package.  This way I can use the original pkg
> tools to delete pango-1.0.4 and all packages that depend on pango,
> without requiring any further changes.

I think it seems to work here because 1) It's only a minor upgrade,
and 2) the soname is properly of the major. What's happens on a major
upgrade? Then all the packages that depend on pango-SO-1.0.3 will
depend on pango-SO-1.0.4, even though there's nothing they need in
there. Even for the minor bump, some binaries that depend on a shared
library that has a dependency on pango will depend on the exact
version (major and minor). In either case, it's incorrect to have a
depencency on pango-SO-1.0.4.

The point is, you can never really tell how packages that depend on
pango will be built. If you replace a package's files with files of
the exact same name, you know you're going to satisfy it's dependencies,
otherwise you can't know.

>   And I can, of course, still use "pkg_hack -a" to upgrade to 1.0.5,
> 1.0.6, 1.0.7, etc. as I can do now.  The only difference is that a
> proper dependency-chain will be built so I can recursively delete all
> packages in one go if I want to.
>
>   This also makes troubleshooting a lot easier if a shared library
> doesn't play by the rules: just "make update" or "pkg_delete -r" and
> reinstall will get rid of all leftover -SO packages and reinstall just
> the newest working package and its dependencies.

As above, or simply "pkg_delete -r pango-\*".

>   I hope this clarifies things somewhat.

What you're saying almost make sense, but what you don't understand,
is that there is never really more than one pango package installed.
(Pretend!) The files registered to pango-SO-* could just as easily be
registered to pango itself (with tags to distinguish their special
nature), or in a subdirectory of pango. The advantage of doing it the
way I have done is that after a "make package" in pango, the resulting
package is *exactly* what you would have gotten by "pkg_delete -r
pango; make package" with the old tools. The resulting packages are
therefore evidently backwards compatible with the old tools -- your
installed package database, however, is not (fully).

Frederick