On Thu, 2002-08-22 at 14:52, Frederick Bruckman wrote:

> libogg-SO-1.0.0.7 doesn't depend on anything in libogg-1.0.0.8.

  What I was thinking about is this: libogg-SO-1.0.0.7 only contains
the shared libraries.  That means that packages depending on libogg
will probably no longer work if you pkg_delete libogg-1.0.0.8, which
then just leaves the shared libraries from the libogg-SO-1.0.0.7
"mini-package", but none of the other (non-library) files installed
by the libogg package.

  Therefore, you would end up with a bunch of packages that are
non-functional, because all that's left are the shared libraries.
This might not be an issue with libogg, or any other packages where
only the shared libraries are relevant.  But if you think of a more
complex package, there might be other resources too that are needed.

  Here is a short example.  Let's assume, there is a package called
"foo".  Version 1.0 of the package installs the following files
(I have left out the symlinks in this illustration):

  lib/libfoo.so.1.0
  share/foo/I_Need_This.xml

  Let's say, package 'bar' requires both files from the 'foo' package.
  An in-place replacement of foo-1.0 by foo-2.0 yields

  lib/libfoo.so.2.0
  share/foo/I_Need_This.xml

  for the foo-2.0 package and

  lib/libfoo.so.1.0

  for the new foo-SO-1.0 package.  If 'bar' only depends on
foo-SO-1.0, it loses its dependency on the 'share/foo/I_Need_This.xml'
file, which might be a vital file for bar's functionality.

  Therefore, bar not only needs to depend on the old foo-SO-1.0
package, but also on the new foo-2.0 package.  This can either be
done through an explicit dependency for 'bar' (and all other such
packages) on 'foo-2.0', or implicitly by making foo-SO-1.0 depend
on foo-2.0.  The latter was what I was suggesting in my previous
mail.

> If you delete libogg-1.0.0.8, you'll leave a libogg-SO-1.0.0.8,

  How's that?  If I "pkg_delete libogg-1.0.0.8", I won't get such
a package, and packages depending on "libogg-SO-1.0.0.7" may now
be in a non-functional state.  Hence, they would require a
dependency on libogg-1.0.0.8.

  IMHO libogg-SO-1.0.0.7 should also depend on libogg-1.0.0.8,
because it does not make much sense then, to leave that lying
around if you deinstall libogg-1.0.0.8.

  This dependency would not affect an in-place upgrade of
libogg-1.0.0.8 to 1.0.0.9 at all (except that it would get
properly recorded).

> >    This also would have the advantage that a 'make update' for
> > libogg should work as expected and cleanly update everything
> > that depends on both the old and the new version of the library.
> 
> "make update" becomes "make install", for most purposes. The hack
> adds any SO packages in the dependencies to the list of packages to be
> built, so you can't go wrong there.

  Yes, I understand.  However, if I wanted to clean up and get rid
of all the old libblah.so shared libraries (and make sure everything
links against the one and only shiny new libblah), I'd still might
want to do a traditional 'make update' from time to time.

  This would work if the dependencies I described above were in
place (and the in-place update would remain unaffected by that).

> If you really want to upgrade *all* the dependents cleanly, you only
> need a tool to put them in order. E.g:

  The above scheme would also make this unnecessary.  A 'make update'
would probably just work out of the box here.

  Cheers
      ,
   Rene