On Thu, 5 Feb 2004 02:27:48 +0100
Spider <[EMAIL PROTECTED]> wrote:

> 
> However, this is bad and broken behaviour as we just get one headache
> for another ( what package supplies -that- .so file then?  which of
> theese 6000 packages is it I haven't installed? and with what USE flag
> combination? )
> 

Sure, if you assume that all libs must be checked because they all may
be broken despite all deps (at pkg level) are satisfied, this is a
difficult problem. But it is really a pessimistic assumption, no?
Cases such as openssl are not that numerous. Openssl is the only one I
can think of, and even if there are other, they are easy to detect a
systematic way. 

If you agree on this, then all you need is something is to check that
this libs are installed in the right version. The two solutions i can
think of:

 - you can do this with a strict dependency as suggested James (I
personnaly think it makes much sense and is a clean solution, now I
don't know how grp packages are built and if it is a problem for you to
have different ebuilds for them.)

 - you can check the installed libs are okay it in pkg_preinst. Since
you specify explicitly what is the problematic libraries, you also know
from what pkg hey come and can report it to the user in case of failure.
Attached is a proof of concept eclass that implement a "checklib"
function you can use this way: 

  pkg_preinst() {
      checklib libssl.so dev-libs/openssl || die
      checklib libcrypto.so dev-libs/openssl || die
  }

The behavior of checklib is to run ldd on all binaries of the package,
find linked libs that match the lib name pattern (for instance
"libssl.so"), and check they exist on system or will be installed. If
they are not, the user is asked to (re-)emerge the package named as 2nd
argument. 
  When the package is built from source, the check should never fail
(or there is a big problem in the build process). When installed from a
binary package, it will fail if the package is not compatible with your
system, and that's it.

What do you think of this second approach (not talking about the code
itself sure)?

-- 
TGL.

Attachment: checklibs.eclass
Description: Binary data

--
[EMAIL PROTECTED] mailing list

Reply via email to