1 |
On Tue, 6 Aug 2013 16:25:12 +0100 |
2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
3 |
|
4 |
> On Mon, 5 Aug 2013 18:49:49 -0400 |
5 |
> Alexis Ballier <aballier@g.o> wrote: |
6 |
> > Again, symbols have nothing to do here. Since you have poor control |
7 |
> > on overlays and absolutely zero control on locally built packages, |
8 |
> > the only sane assumption is that all symbols are used. |
9 |
> |
10 |
> And that answers your question as to why the spec says "may". |
11 |
|
12 |
Not really: This explains why there _must_ be another way than subslots |
13 |
to check this. elf libraries have soname, some other systems that |
14 |
lack it, such as ocaml, have quite restrictive build time/runtime |
15 |
checks to avoid messing up. |
16 |
If I build locally a program of mine that all of a sudden starts to |
17 |
provide me false results because nobody told me I had to rebuild it, |
18 |
I'd be quite upset. |
19 |
Changing soname is the well established standard notification for this. |
20 |
With a soname change it's not really a 'may' but rather a 'must'... |
21 |
same with ocaml for example. |
22 |
|
23 |
|
24 |
> > > That's covered by the spec. Basically, ignoring many of the |
25 |
> > > complications that make dependency resolution such a pain, for a |
26 |
> > > dependency to be usable, all its dependencies must be usable. |
27 |
> > > |
28 |
> > > The "may" there is simply there to avoid prohibiting developers |
29 |
> > > from doing a subslot bump when it could turn out not to be |
30 |
> > > necessary after all. |
31 |
> > |
32 |
> > And then when a package has various libraries, one being very |
33 |
> > unstable abi-wise and the others stable, it seems much more sane |
34 |
> > not to := depend on said package if you only use the stable ones |
35 |
> > when the subslot clearly refers to the unstable abi library. |
36 |
> |
37 |
> But that leads to breakage when the "stable" ABI changes. It's better |
38 |
> to avoid breakage than it is to require the odd extra recompile. |
39 |
|
40 |
That's why preserve-libs is still the proper way to do it until we have |
41 |
a more accurate subslot handling. In the poppler case, the stable ABI |
42 |
changes an order of magnitude less often than the unstable one; it's |
43 |
not really 'the' extra recompile but rather hundreds of them if you |
44 |
multiply by the # of dependent packages. Claiming it's better to have |
45 |
hundreds of recompiles is simply being lazy, throwing our failures onto |
46 |
users, and not be willing to fix the real problem. |
47 |
|
48 |
> > > > Supposing we are dealing with shared libraries only, how is that |
49 |
> > > > an improvement over preserve-libs ? |
50 |
> > > |
51 |
> > > We aren't dealing with shared libraries only. Even if we were, a) |
52 |
> > > shared libraries have dependencies upon things that are not shared |
53 |
> > > libraries, like text files, and b) subslots don't facilitate using |
54 |
> > > an old, insecure shared library to generate content. |
55 |
> > |
56 |
> > I don't see how current subslots improve a) |
57 |
> |
58 |
> With subslots, the developer specifies dependencies. With fix-linkage, |
59 |
> the package mangler has to guess based upon very incomplete |
60 |
> information. |
61 |
|
62 |
You're assuming library maintainers are stupid: If done properly, |
63 |
there is a library that gives you the text file location based on where |
64 |
it has been installed. If that's not the case then that's where I'd try |
65 |
to improve things, not hiding the problem behind a subslot. |
66 |
|
67 |
> > and b) is just a matter of UI defaults... |
68 |
> |
69 |
> No, b) doesn't happen with correctly done subslots. |
70 |
|
71 |
neither with a preserve-libs implementation that, by default, would run |
72 |
@preserved-rebuild after detecting there are preserved libraries and |
73 |
would refuse to merge anything but the broken packages if there are |
74 |
preserved libraries. |