On 26 Aug 2002, Rene Hexel wrote:

> On Fri, 2002-08-23 at 08:40, Frederick Bruckman wrote:
>
> > What happens when you delete the new package and reinstall the old
> > one? Wouldn't the resulting package recursively depend on itself?
>
>   No.  If you did a 'pkg_delete/pkg_add' combination, the dependency
> would make sure that the pkg-SO-oldversion would get deleted before you
> install a newer version with pkg_add.

No it wouldn't. The only time the hack currently deletes a "SO"
package is *after* another package replaces its last file, and even
then, it's only automatic if you use "pkg_hack -a" or "make install"
(but you can still invoke "pkg_hack -c" manually).

During the normal course of events, you'll get plenty of "SO" packages
emptied of files and emptied of dependencies, and you're just supposed
to delete those manually.

>   pkg_hack would, of course, need to detect cases where
> pkg-SO-oldversion would get replaced by pkg-oldversion (both versions
> being the same).

I'm not sure what you mean. Currently, when you replace the last
shared library, you get all the dependencies of the package that had
the shared library you replaced.

>   Here is an example I just tried:
>
>
> $ pkg_info -R pango\*
> Information for pango-1.0.3nb1:
>
> Required by:
> gtk2+-2.0.5nb1
>
>
> $ gtk-demo
> program runs fine
>
> $ pkg_hack -a pango-1.0.4.tgz
> $ pkg_info -R pango\*
> Information for pango-1.0.4:
>
>
> Information for pango-SO-1.0.3nb1:
>
> Required by:
> gtk2+-2.0.5nb1
>
>
> $ pkg_delete pango-1.0.4

Don't do that! You should have done "pkg_hack -d pango".

> $ pkg_info -R pango\*
> Information for pango-SO-1.0.3nb1:
>
> Required by:
> gtk2+-2.0.5nb1
>
>
> $ gtk-demo
> Shared object "libpangoxft-1.0.so.0" not found

If you'd used "pkg_hack -d", that shared library would still be on the
system, and owned by "pango-SO-1.0.4". You have to be able to delete
pango-1.0.4 in order to upgrade it, to say pango-1.0.5, or to revert
it to pango-1.0.3. If you succeed in preventing that by adding
dependencies, you'll just stop all progress.

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. All you really need
is for that shared library to be retained, and it will be if you use
"pkg_hack -d" instead of "pkg_delete".

>   As you can see, when I delete pango-1.0.4, the package system is in an
> inconsistent state, because it leaves pango-SO-1.0.3nb1 plus its
> dependencies, which are now in a non-working state, because the
> prerequisite files in pango-1.0.4 (they depend on) are no longer
> present.

That's why it's called "pkg_hack". It's not foolproof. You're
specifically warned against using the naked pkg tools while there are
still "SO" cognates on the system. (The exception is to delete
empties.) Once the actual pkg_* binaries are modified, the situation
you describe can not arise, as deleting a package with all its
cognates will require "-r", just like deleting a package does now.

>   Everything works fine if pango-SO-1.0.3 depends on pango-1.0.4.

That's the part I don't get, as "pkg_hack -d pango" essentially
steam-rollers over any dependencies on pango.

Frederick