On Mon, 2002-08-26 at 22:34, Frederick Bruckman wrote:

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

  That's not correct.

  In fact, it's the other way round.  Most packages, like pango, not
only supply shared libraries, but also a lot of other files like
documentation, configuration, and other support files.

  One way would be to @keep all of these files as you suggest.  However,
if you look at non-trivial packages (that not only supply a shared
library), you will find that most of these packages would then require
@keep for almost all of their PLIST.

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

  I'm not talking about shared libraries here.  I'm talking about
*packages*, which contain a whole lot more than just shared libraries.

  What you are saying is that preserving the shared libraries in the -SO
packages is sufficient to satisfy dependent packages.  I'm showing you
that this is simply not the case.

  Just have a look at QT, KDE, GNOME, and tons of other packages.  Try
doing a 'pkg_hack -d' on one of the core library packages and see most
of the dependent packages fail.  They will fail until you 'pkg_hack -a'
an updated version, which will install the missing support files.  Which
means there is also not only a dependency on the old -SO leftover, but
also on the new, upgraded package!

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

  I agree.  But as long as you cannot be certain, having a proper
dependency is the safe way to go.  Not having such a dependency will
always fail, except in the most trivial cases.

  I do agree that @keep is necessary and solves some of these problems. 
I still believe, though, that having a proper dependency is desirable.

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

  It probably all comes down to that.

  What you are proposing is to change the pkg tools to turn a
"pkg_delete -r pango" effectively into a "pkg_delete -r pango{,-SO}".

  What I'm trying to explain is that with a proper dependency there is
no need to change for such a drastic change to the pkg tools.

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

  I appreciate that.  I think having a separate pango-SO package is a
good idea, not only to make new pango packages binary compatible with
ones that would have been compiled "from scratch" (i.e. without the
previous one installed).

  And yes, I do think of the -SO package as a sub- or "compatible"
package that should be treated as part of the pango (or whatever)
package.

  The only part where we differ is the means this should be done with. 
You are suggesting to change the pkg tools so 'pkg_delete' effectively
becomes equal to 'pkg_hack -d' by treating -SO packages specially.

  What I am suggesting is that 'pkg_delete' would work fine as it is if
that dependency was in place.  What's more important, it would allow a
finer control over what you want to do:

  * You can simply delete a package and its dependencies using
'pkg_delete -r' without leaving any leftover shared libraries as you can
do now.

  * You could 'pkg_delete -r' the -SO package (and its dependencies). 
This would allow you to get rid of the old package and all of its
dependencies, i.e. if you later on plan to rebuild them from scratch so
that the old shared libraries are no longer required.

  * You can 'pkg_hack -d' and leave the shared libraries.  In most
cases, this is only useful if you subsequently

  * 'pkg_hack -a' to upgrade a package in place.

> The resulting packages are
> therefore evidently backwards compatible with the old tools -- your
> installed package database, however, is not (fully).

  Huh?

  The reason why I suggested this behaviour was that such a dependency
makes it more compatible with existing pkg tools than what pkg_hack is
doing now.

  Maybe if you could give me a concrete example to explain what your
concerns are.  I really don't see any harm in having a dependency that
is consistent with what we have in the package system now.

  Cheers
      ,
   Rene