| 1 |
On Tue, 6 Aug 2013 17:30:56 +0100 |
| 2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
| 3 |
|
| 4 |
> On Tue, 6 Aug 2013 12:16:57 -0400 |
| 5 |
> Alexis Ballier <aballier@g.o> wrote: |
| 6 |
> > On Tue, 6 Aug 2013 16:25:12 +0100 |
| 7 |
> > Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
| 8 |
> > > On Mon, 5 Aug 2013 18:49:49 -0400 |
| 9 |
> > > Alexis Ballier <aballier@g.o> wrote: |
| 10 |
> > > > Again, symbols have nothing to do here. Since you have poor |
| 11 |
> > > > control on overlays and absolutely zero control on locally built |
| 12 |
> > > > packages, the only sane assumption is that all symbols are used. |
| 13 |
> > > |
| 14 |
> > > And that answers your question as to why the spec says "may". |
| 15 |
> > |
| 16 |
> > Not really: This explains why there _must_ be another way than |
| 17 |
> > subslots to check this. |
| 18 |
> |
| 19 |
> Only if you want to avoid ever having an unnecessary rebuild. That |
| 20 |
> isn't a sensible goal. |
| 21 |
|
| 22 |
|
| 23 |
You haven't read the part you cut it seems. |
| 24 |
|
| 25 |
|
| 26 |
> > > But that leads to breakage when the "stable" ABI changes. It's |
| 27 |
> > > better to avoid breakage than it is to require the odd extra |
| 28 |
> > > recompile. |
| 29 |
> > |
| 30 |
> > That's why preserve-libs is still the proper way to do it until we |
| 31 |
> > have a more accurate subslot handling. |
| 32 |
> |
| 33 |
> preserve-libs is broken by design. All you need is proper use of |
| 34 |
> subslots, and to recognise that the occasional unnecessary rebuild |
| 35 |
> isn't a big deal. |
| 36 |
|
| 37 |
preserve-libs has its flaws. All you need is improving the subslot |
| 38 |
system so that it can be used properly. What are you waiting for ? :) |
| 39 |
|
| 40 |
'occasional unnecessary rebuild' is a big deal since subslots introduce |
| 41 |
this regression... |
| 42 |
|
| 43 |
> > In the poppler case, the |
| 44 |
> > stable ABI changes an order of magnitude less often than the |
| 45 |
> > unstable one; it's not really 'the' extra recompile but rather |
| 46 |
> > hundreds of them if you multiply by the # of dependent packages. |
| 47 |
> > Claiming it's better to have hundreds of recompiles is simply being |
| 48 |
> > lazy, throwing our failures onto users, and not be willing to fix |
| 49 |
> > the real problem. |
| 50 |
> |
| 51 |
> There's an easy fix for that: split the package up. |
| 52 |
|
| 53 |
|
| 54 |
Great, please start submitting patches at our thousands of upstreams so |
| 55 |
that their packages can be split properly. |
| 56 |
|
| 57 |
|
| 58 |
> > > With subslots, the developer specifies dependencies. With |
| 59 |
> > > fix-linkage, the package mangler has to guess based upon very |
| 60 |
> > > incomplete 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 |
| 64 |
> > where it has been installed. If that's not the case then that's |
| 65 |
> > where I'd try to improve things, not hiding the problem behind a |
| 66 |
> > subslot. |
| 67 |
> |
| 68 |
> That's no good when that file is removed or overwritten by a newer |
| 69 |
> format, but preserve-libs leaves the .so that uses that file behind. |
| 70 |
|
| 71 |
Then submit patches to run preserve-libs as soon as possible as I |
| 72 |
suggested in the part you cut. preserve-libs, in contrast to just |
| 73 |
removing the .so, leaves you with a working system in 90% of the cases. |
| 74 |
|
| 75 |
Exercise: Try to update a FreeBSD 6 system (libc.so.6) to a FreeBSD 7 |
| 76 |
system (libc.so.7) without some kind of preserve-libs mechanism. |
| 77 |
Been there, done that. The flaws of preserve-libs show up but it |
| 78 |
maintains a half working system all the way long that allows you to |
| 79 |
finish the update. |
Archives