On Mon, 2002-08-26 at 12:11, Frederick Bruckman wrote:

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

  That may be what the hack is doing at the moment (and this may be the
cause of our misunderstanding).  What I'm saying is that *if* this
dependency was in place, it would work out of the box with the current
package system (i.e. "pkg_delete -r").

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

  I was merely following up on your statement about circular
dependencies:

  pkg_add foo-1.0
  pkg_hack -a foo-2.0 (creates foo-SO-1.0)
  pkg_hack -a foo-1.0 (should remove foo-SO-1.0)

  I may have misunderstood you here.  If that's the case, could you
please elaborate what you mean by "Wouldn't the resulting package
recursively depend on itself?"

> Currently, when you replace the last
> shared library, you get all the dependencies of the package that had
> the shared library you replaced.

  Yes, but that's not sufficient.  From my example, you can see that
gtk2 depends on pango-1.0.4 as well as pango-SO-1.0.3.  That dependency
is currently not added by pkg_hack.

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

  I know.

  What I'm saying is: with adding that small dependency, a normal
"pkg_delete -r pango-1.0.4" would have worked out of the box to delete
these packages without the special behaviour "pkg_hack -d" introduces.
There is no need for a special "pkg_hack -d" to simply delete packages.
If that dependency was in place, that is.

  Is there any particular reason why you *don't* want this dependency? 
I just tried tweaking the +REQUIRED_BY and +CONTENTS by hand so that
pango-SO-1.0.3 now requires pango-1.0.4 everything is working just fine!

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

> You have to be able to delete
> 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.

  If I wanted to upgrade pango-1.0.4 to pango-1.0.5 things would work as
expected.  There would be two ways of doing this.  With "pkg_hack -a", I
would get (assuming the dependencies I was talking about were in place):

  ORIGINAL:
  pango-1.0.3
  gtk2+-2.0.5 (pango-1.0.3)

  UPGRADE to pango-1.0.4 using pkg_hack:
  pango-1.0.4
  pango-SO-1.0.3 (depends on pango-1.0.4)
  gtk2+-2.0.5 (depends on pango-SO-1.0.3)

  UPGRADE to pango-1.0.5 using pkg_hack:
  pango-1.0.5
  pango-SO-1.0.4 (depends on pango-1.0.5)
  pango-SO-1.0.3 (depends on pango-SO-1.0.4)
  gtk2+-2.0.5 (depends on pango-SO-1.0.3)


  Or the traditional way (from 1.0.4 to 1.0.5):

  ORIGINAL:
  pango-1.0.3
  gtk2+-2.0.5 (pango-1.0.3)

  UPGRADE to pango-1.0.4 using pkg_hack:
  pango-1.0.4
  pango-SO-1.0.3 (depends on pango-1.0.4)
  gtk2+-2.0.5 (depends on pango-SO-1.0.3)

  UPGRADE to pango-1.0.5 using
      pkg_delete -r pango-1.0.4
      pkg_add pango-1.0.5
      pkg_add gtk2+-2.0.5
  yields:
  pango-1.0.5
  gtk2+-2.0.5 (depends on pango-1.0.5)


  Using the latter method I have a package tree again that isn't
globbered by leftover shared libraries from pango-1.0.3 and 1.0.4.

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

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

  Using my approach will not preclude "pkg_hack -d" from working.  It
just makes "pkg_delete" an option, without requiring it to become aware
of the special cases of shared libraries.

> That's why it's called "pkg_hack". It's not foolproof. You're

  I know, and I do appreciate the work you have done!  I believe this
can be a useful addition to the package system.

> specifically warned against using the naked pkg tools while there are
> still "SO" cognates on the system. (The exception is to delete

  That's why I was proposing a way of making it interact better with the
existing pkg tools!

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

  Yes, that's fine.  Everything that depended on pango-1.0.3 now depends
on pango-SO-1.0.3.  That's how it should be.

  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.

  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.

  I hope this clarifies things somewhat.

  Cheers
      ,
   Rene