| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On Thursday 05 February 2004 04:57, Thomas de Grenier de Latour wrote: |
| 5 |
> |
| 6 |
> Sure, if you assume that all libs must be checked because they all may |
| 7 |
> be broken despite all deps (at pkg level) are satisfied, this is a |
| 8 |
> difficult problem. But it is really a pessimistic assumption, no? |
| 9 |
> Cases such as openssl are not that numerous. Openssl is the only one I |
| 10 |
> can think of, and even if there are other, they are easy to detect a |
| 11 |
> systematic way. |
| 12 |
|
| 13 |
They are, you just don't know which packages it are. This is especially a |
| 14 |
problem with installing new packages on an old base (ever tried to |
| 15 |
downgrade glibc/gcc?) |
| 16 |
|
| 17 |
> |
| 18 |
> If you agree on this, then all you need is something is to check that |
| 19 |
> this libs are installed in the right version. The two solutions i can |
| 20 |
> think of: |
| 21 |
> |
| 22 |
> - you can do this with a strict dependency as suggested James (I |
| 23 |
> personnaly think it makes much sense and is a clean solution, now I |
| 24 |
> don't know how grp packages are built and if it is a problem for you |
| 25 |
> to have different ebuilds for them.) |
| 26 |
|
| 27 |
It is an incredible cludge, you want to record which versions a package |
| 28 |
was build with, but you don't want to depend on exactly that version. |
| 29 |
|
| 30 |
> - you can check the installed libs are okay it in pkg_preinst. Since |
| 31 |
> you specify explicitly what is the problematic libraries, you also |
| 32 |
> know from what pkg hey come and can report it to the user in case of |
| 33 |
> failure. Attached is a proof of concept eclass that implement a |
| 34 |
> "checklib" function you can use this way: |
| 35 |
|
| 36 |
Basicaly every and all libs are problematic. Since dependencies for run |
| 37 |
and compile time are almost allways libraries, the problem exists for |
| 38 |
allmost all dependencies. This is not a small problem, so doing things |
| 39 |
manually is not an option except for exceptions to the general rule. |
| 40 |
|
| 41 |
> |
| 42 |
> pkg_preinst() { |
| 43 |
> checklib libssl.so dev-libs/openssl || die |
| 44 |
> checklib libcrypto.so dev-libs/openssl || die |
| 45 |
> } |
| 46 |
> |
| 47 |
> The behavior of checklib is to run ldd on all binaries of the package, |
| 48 |
> find linked libs that match the lib name pattern (for instance |
| 49 |
> "libssl.so"), and check they exist on system or will be installed. If |
| 50 |
> they are not, the user is asked to (re-)emerge the package named as |
| 51 |
> 2nd argument. |
| 52 |
> When the package is built from source, the check should never fail |
| 53 |
> (or there is a big problem in the build process). When installed from |
| 54 |
> a binary package, it will fail if the package is not compatible with |
| 55 |
> your system, and that's it. |
| 56 |
> |
| 57 |
> What do you think of this second approach (not talking about the code |
| 58 |
> itself sure)? |
| 59 |
|
| 60 |
It is a laborous kludge, and will not work (trust me, getting 200 devs to |
| 61 |
do things is hard, especially if things work without it). |
| 62 |
|
| 63 |
Paul |
| 64 |
|
| 65 |
- -- |
| 66 |
Paul de Vrieze |
| 67 |
Gentoo Developer |
| 68 |
Mail: pauldv@g.o |
| 69 |
Homepage: http://www.devrieze.net |
| 70 |
-----BEGIN PGP SIGNATURE----- |
| 71 |
Version: GnuPG v1.2.4 (GNU/Linux) |
| 72 |
|
| 73 |
iD8DBQFAIhUAbKx5DBjWFdsRAlknAJ9yUN4WeAzo4Cz9Nt25x9BD/DTiQgCfQi+U |
| 74 |
g2ri1yx/CFfaK/AhYMb22gs= |
| 75 |
=9gI4 |
| 76 |
-----END PGP SIGNATURE----- |
| 77 |
|
| 78 |
-- |
| 79 |
gentoo-dev@g.o mailing list |
Archives