On Tue, 6 Aug 2013 16:25:12 +0100 Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> On Mon, 5 Aug 2013 18:49:49 -0400 > Alexis Ballier <aball...@gentoo.org> wrote: > > Again, symbols have nothing to do here. Since you have poor control > > on overlays and absolutely zero control on locally built packages, > > the only sane assumption is that all symbols are used. > > And that answers your question as to why the spec says "may". Not really: This explains why there _must_ be another way than subslots to check this. elf libraries have soname, some other systems that lack it, such as ocaml, have quite restrictive build time/runtime checks to avoid messing up. If I build locally a program of mine that all of a sudden starts to provide me false results because nobody told me I had to rebuild it, I'd be quite upset. Changing soname is the well established standard notification for this. With a soname change it's not really a 'may' but rather a 'must'... same with ocaml for example. > > > That's covered by the spec. Basically, ignoring many of the > > > complications that make dependency resolution such a pain, for a > > > dependency to be usable, all its dependencies must be usable. > > > > > > The "may" there is simply there to avoid prohibiting developers > > > from doing a subslot bump when it could turn out not to be > > > necessary after all. > > > > And then when a package has various libraries, one being very > > unstable abi-wise and the others stable, it seems much more sane > > not to := depend on said package if you only use the stable ones > > when the subslot clearly refers to the unstable abi library. > > But that leads to breakage when the "stable" ABI changes. It's better > to avoid breakage than it is to require the odd extra recompile. That's why preserve-libs is still the proper way to do it until we have a more accurate subslot handling. In the poppler case, the stable ABI changes an order of magnitude less often than the unstable one; it's not really 'the' extra recompile but rather hundreds of them if you multiply by the # of dependent packages. Claiming it's better to have hundreds of recompiles is simply being lazy, throwing our failures onto users, and not be willing to fix the real problem. > > > > Supposing we are dealing with shared libraries only, how is that > > > > an improvement over preserve-libs ? > > > > > > We aren't dealing with shared libraries only. Even if we were, a) > > > shared libraries have dependencies upon things that are not shared > > > libraries, like text files, and b) subslots don't facilitate using > > > an old, insecure shared library to generate content. > > > > I don't see how current subslots improve a) > > With subslots, the developer specifies dependencies. With fix-linkage, > the package mangler has to guess based upon very incomplete > information. You're assuming library maintainers are stupid: If done properly, there is a library that gives you the text file location based on where it has been installed. If that's not the case then that's where I'd try to improve things, not hiding the problem behind a subslot. > > and b) is just a matter of UI defaults... > > No, b) doesn't happen with correctly done subslots. neither with a preserve-libs implementation that, by default, would run @preserved-rebuild after detecting there are preserved libraries and would refuse to merge anything but the broken packages if there are preserved libraries.
