1 |
begin quote |
2 |
On Thu, 5 Feb 2004 21:57:42 +0100 |
3 |
Paul de Vrieze <pauldv@g.o> wrote: |
4 |
|
5 |
> On Thursday 05 February 2004 21:34, Spider wrote: |
6 |
> > begin quote |
7 |
> > On Thu, 5 Feb 2004 20:58:01 +0100 |
8 |
> > Can you explain more? When would LIBVER be set? by whom? (developer? |
9 |
> > no thanks.. :P ) and woudn't there need to be one LIBVER per .so |
10 |
> > file that a package installs? |
11 |
> |
12 |
> In most cases we could probably derive it automatically from the |
13 |
> soname of a library, in special cases LIBVER would need to be set. |
14 |
> Basically the idea breaks through the one LIBVER per .so by needing a |
15 |
> developer to define a different LIBVER when an incompatible library |
16 |
> change is introduced in the package (in any file) (the contents of |
17 |
> LIBVER don't matter). In some cases this will be automatically |
18 |
> detected, in some cases not, in which the developer needs to fix this. |
19 |
> |
20 |
|
21 |
|
22 |
I'm still not sure I actually understand how this would hang about. |
23 |
LIBVER would be created for the package at post-compile time, and would |
24 |
refer to its own contents... right? |
25 |
|
26 |
This could work, but in cases like : |
27 |
foolib.so.0 -> foolib.so.0.5.4 |
28 |
|
29 |
Which is LIBVER? 0, or 0.5.4 ? since if applications link to .so.0 |
30 |
the binaries will break if LIBVER is 0.5.4 (due to dependencies) but if |
31 |
it provides both, and a program links to the hard minor (0.5.4) , |
32 |
LIBVER would break if it was "0" ... |
33 |
|
34 |
This falls on the fact that all packages don't necessarily link to the |
35 |
same LIBVER , some may link to .so.0, others may be pickier and link to |
36 |
`foolib.so.0.5.4` .. Not a pretty situation. |
37 |
|
38 |
<SNIP> |
39 |
|
40 |
> |
41 |
> That would be "enhanced rpm style", which would probably work too. It |
42 |
> would however not solve the problem of determining which versions are |
43 |
> actually compatible (one could use sonames for that) |
44 |
|
45 |
No, that wouldn't be solved , but you'd at least have a "safety net" |
46 |
that catches you when you fall down to binaries. IE installing |
47 |
"foopack" won't be allowed if the contents wouldn't work (well, override |
48 |
flags, but I think that would be a bad thing. simply not having a |
49 |
--force would avoid some user-generated problems here ;) |
50 |
|
51 |
|
52 |
|
53 |
> |
54 |
> > and yes. its dirty. its rpmish. and I'd love to see a better |
55 |
> > thing. however, its better than the thing we have currently. |
56 |
> |
57 |
> Anything is better than nothing (which we have now) ;-) |
58 |
|
59 |
hehe :) |
60 |
|
61 |
|
62 |
> > Any ideas? |
63 |
> Don't have binary packages ;-) |
64 |
|
65 |
not very practical IMO. computers aren't that fast, yet. (and with |
66 |
software like KDE, Mozilla, qt, OpenOffice.. May never be) |
67 |
|
68 |
//Spider |
69 |
|
70 |
-- |
71 |
begin .signature |
72 |
This is a .signature virus! Please copy me into your .signature! |
73 |
See Microsoft KB Article Q265230 for more information. |
74 |
end |