Please use EAPI=5 subslot operator := in app-text/poppler dependencies, so the poppler rdeps are re-built automatically by portage after a poppler upgrade. (Maximally complicated) example from kde-base/okular: DEPEND=" pdf? ( >=app-text/poppler-0.20:=[qt4,-exceptions(-)] ) " The following packages should be improved: app-editors/gummi app-leechcraft/lc-monocle app-misc/recoll app-office/calligra app-office/texmaker app-office/texstudio app-text/apvlv app-text/cb2bib app-text/diffpdf app-text/dvipdfmx app-text/evince app-text/ghostscript-gpl app-text/kbibtex app-text/pdf2djvu app-text/pdf2oo app-text/pdfgrep app-text/poppler-data app-text/qpdfview app-text/referencer app-text/texlive-core app-text/xournal app-text/yagf app-text/zathura-pdf-poppler dev-games/openscenegraph dev-python/matplotlib dev-python/python-poppler dev-python/python-poppler-qt4 dev-ruby/ruby-poppler dev-tex/luatex dev-tex/pdftex dev-tex/pstplus kde-misc/tellico mail-client/claws-mail-pdf-viewer media-gfx/gimp media-gfx/inkscape media-gfx/pdf2svg media-plugins/evas_generic_loaders net-print/cups net-print/cups-filters sci-electronics/cirkuit sci-libs/gdal sys-cluster/charm www-apps/dotproject www-apps/swish-e x11-misc/qcomicbook xfce-extra/tumbler
(In reply to comment #0) > app-office/texmaker > app-office/texstudio Fixed.
(In reply to comment #0) > app-text/kbibtex > app-text/pdf2oo > app-text/xournal > sci-electronics/cirkuit Fixed.
(In reply to comment #0) > app-text/apvlv > app-text/pdf2djvu > app-text/zathura-pdf-poppler > media-gfx/pdf2svg > xfce-extra/tumbler Fixed these. No idea who to unCC except xfce@
> net-print/cups (does not link to poppler) > net-print/cups-filters Fixed
Updated full list: app-editors/gummi app-leechcraft/lc-monocle app-misc/recoll app-text/dvipdfmx app-text/evince app-text/ghostscript-gpl app-text/referencer app-text/texlive-core app-text/yagf dev-games/openscenegraph dev-python/matplotlib dev-python/python-poppler dev-python/python-poppler-qt4 dev-ruby/ruby-poppler dev-tex/luatex dev-tex/pdftex dev-tex/pstplus mail-client/claws-mail-pdf-viewer media-gfx/gimp media-gfx/inkscape media-plugins/evas_generic_loaders sci-libs/gdal sys-cluster/charm www-apps/dotproject www-apps/swish-e x11-misc/qcomicbook
matplotlib does not appear to link with poppler -- is there any reason to rebuild it?
(In reply to comment #6) > matplotlib does not appear to link with poppler -- is there any reason to > rebuild it? No, it's fine then as it is. (Cups is a similar case, it only uses the commandline utilities.)
Did someone already notice that this is a bad solution? Many of these applications use poppler-glib or poppler-qt. I've recently bisected a bug in poppler and within all the releases I've tested, *neither* of those libraries changed SONAME while libpoppler did it almost every release. Shortly saying, this means that with the := dep, every poppler upgrade will rebuild a number of random applications which don't need to be rebuilt at all, including evince, qpdfview, gimp... Could we finally stop this subslot insanity and use preserved-libs?
app-text/yagf - done
These are done: dev-python/matplotlib dev-python/python-poppler dev-python/python-poppler-qt4 (In reply to comment #8) > Did someone already notice that this is a bad solution? It certainly is not ideal, but it is probably better to error by rebuilding too much than too little. To make it work correctly would require splitting poppler into several packages. There's always the --rebuild-if-new-slot=n option if you prefer the old portage behavior.
i suspect poppler should be fixed upstream instead, to avoid changing soname so often, there has not been serious backward incompatibility since 0.19.3, see: http://upstream-tracker.org/versions/poppler.html
(In reply to comment #8) > Did someone already notice that this is a bad solution? > > Many of these applications use poppler-glib or poppler-qt. I've recently > bisected a bug in poppler and within all the releases I've tested, *neither* > of those libraries changed SONAME while libpoppler did it almost every > release. > > Shortly saying, this means that with the := dep, every poppler upgrade will > rebuild a number of random applications which don't need to be rebuilt at > all, including evince, qpdfview, gimp... > > Could we finally stop this subslot insanity and use preserved-libs? I concur this. dillfridge, you could at least give more time for this 'decision' (I am poppler maintainer..) to settle down. Subslot operator should be used only when ABI is known to change *without* SOVERSION bump or certain package is provided only as static library (plib comes to my mind). Otherwise this is overkill - preserved libs works pretty well here. Please revert those changes!
(In reply to comment #12) > Subslot operator should be used only when ABI is known to change *without* > SOVERSION bump or certain package is provided only as static library (plib > comes to my mind). Otherwise this is overkill - preserved libs works pretty > well here. That's simply wrong as I understand the feature. One of the selling points of slot-operator deps was that the user should not need to run revdep-rebuild or emerge @preserved-rebuild manually.
Bug #462138 suggests proper solution for future EAPIs.
(In reply to comment #13) > (In reply to comment #12) > > Subslot operator should be used only when ABI is known to change *without* > > SOVERSION bump or certain package is provided only as static library (plib > > comes to my mind). Otherwise this is overkill - preserved libs works pretty > > well here. > > That's simply wrong as I understand the feature. > > One of the selling points of slot-operator deps was that the user should not > need to run revdep-rebuild or emerge @preserved-rebuild manually. Actually I agree with Mike here, which is why I am not going to revert anything. Feel free to do it yourself though, I will not interfere anymore. [Seems like we have yet another new feature that everyone refuses to use.] And btw Arf's idea is probably technically correct. It just places even bigger burden on the maintainer...
(In reply to comment #12) > I concur this. dillfridge, you could at least give more time for this > 'decision' (I am poppler maintainer..) to settle down. Please update metadata.xml with more information about your wishes or just drop the herd entries if you do not want other people touching the package. > Subslot operator should be used only when ABI is known to change *without* > SOVERSION bump or certain package is provided only as static library (plib > comes to my mind). Otherwise this is overkill - preserved libs works pretty > well here. This statement is patently false. > > Please revert those changes! The only reversions that should occur are for packages that link only to stable-abi libraries from poppler (like poppler-glib or poppler-qt) as noticed by Michał.
As per previous comment, re-CCing maintainers of packages that have been changed to use subslots, but only link to the typically-stable poppler-glib or poppler-qt (or I was not able to check) so that maintainers can decide if the subslot dependency is really right for their package: app-office/texmaker app-office/texstudio app-text/xournal app-text/apvlv app-text/zathura-pdf-poppler media-gfx/pdf2svg xfce-extra/tumbler app-text/yagf (poppler is not a build dep here anyway) (Some packages missing from this list have already been fixed or maintainer as indicated they prefer to keep the subslot anyway).
This could also be solved by splitting poppler, but not sure if it would be feasible :S
I go with the subslot operator on > mail-client/claws-mail-pdf-viewer
Arfrever's idea leaves for maintainer to track all SOVERSION deps in ebuild which may sound fair but is overkill to maintain. poppler internal (libpoppler) library changes SOVERSION usually with every release. This is why -glib, -qt or -cpp bindings were introduced - their ABI is more stable and they're the proper way to use library. Sadly, many programs (like luatex) still insist on using xpdf headers (and therefore libpoppler directly) - which is asking for trouble with every poppler release. Btw, poppler will not be split (again). Been there, done that.
(In reply to comment #20) [...] > Btw, poppler will not be split (again). Been there, done that. Why was it unsplitted? Thanks for the information :)
(In reply to comment #17) > app-text/yagf (poppler is not a build dep here anyway) Yeah, my bad, it needs it only in runtime, so i have reverted dependency on it back(without subslot operator)
(In reply to comment #21) > (In reply to comment #20) > [...] > > Btw, poppler will not be split (again). Been there, done that. > > Why was it unsplitted? Thanks for the information :) For a small package it is, maintaining split ebuilds poppler ebuilds caused unproportional bildsystem and dependencies related maintenance burden. /me looks suspiciously at gstreamer herd
Maybe would be then feasible to only split out libpoppler. That would only mean one more package to maintain, but we would be able to set proper ":=" deps for most of the cases. What do you think?
No, I don't feel like maintaining patches to provide split build system. I don't have to tell that I'm completely unconvinced with this := madness where preserved-libs does_the_job™.
(In reply to comment #25) > No, I don't feel like maintaining patches to provide split build system. > I don't have to tell that I'm completely unconvinced with this := madness > where preserved-libs does_the_job™. I don't have problems with relying on preserved-libs, but, looking to: http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/ Looks like it won't be enabled by default until automatic rebuilds are done (to prevent people from forgetting to run emerge @preserved-rebuild)
(In reply to comment #26) > Looks like it won't be enabled by default until automatic rebuilds are done > (to prevent people from forgetting to run emerge @preserved-rebuild) The worse problem with preserve-libs/@preserved-rebuild is that it does not trigger rebuilds early enough, so you can end up with build failures due to symbol collisions or other unforeseeable reasons.
Maybe one approach would be to make emerge to automatically run "emerge @preserved-rebuild" just after first lib is preserved and, after that, continue updating other things
(In reply to comment #28) > Maybe one approach would be to make emerge to automatically run "emerge > @preserved-rebuild" just after first lib is preserved and, after that, > continue updating other things This means that the package manager has to stop and re-calculate dependencies each time that it finds a library to preserve (and the dependency calculation might fail for example if one of the ebuilds that needs to be rebuilt is masked or unavailable). It's annoying for users because they won't know in advance what packages need to be rebuild (such as a libreoffice rebuild triggered by an icu upgrade).
And what about doing that automatic "emerge @preserved-rebuild" run only when merge fails and "--keep-going" is used?
(In reply to comment #30) > And what about doing that automatic "emerge @preserved-rebuild" run only > when merge fails and "--keep-going" is used? Well, @preserved-rebuild is also sub-optimal since it doesn't exclude packages which are eligible for removal by --depclean (that's what bug 364425 was about). I suppose we could change that, but I don't personally feel motivated to develop @preserved-rebuild in this direction, given that slot-operator deps seem to solve the problem so much more elegantly.
(In reply to comment #31) > 364425 was about). I suppose we could change that, but I don't personally > feel motivated to develop @preserved-rebuild in this direction, given that > slot-operator deps seem to solve the problem so much more elegantly. Except when they trigger dozens of unnecessary rebuilds or simply don't work at all because someone wanted to avoid those rebuilds.
(In reply to comment #32) > Except when they trigger dozens of unnecessary rebuilds or simply don't work > at all because someone wanted to avoid those rebuilds. Is this anything that won't be solved subslot dictionaries as suggested in bug 462138?
(In reply to comment #33) > (In reply to comment #32) > > Except when they trigger dozens of unnecessary rebuilds or simply don't work > > at all because someone wanted to avoid those rebuilds. > > Is this anything that won't be solved subslot dictionaries as suggested in > bug 462138? That would for sure be the most elegant way, the problem is that I am unsure about how long could take to implement it as I have read in affected bug reports :|
(In reply to comment #33) > (In reply to comment #32) > > Except when they trigger dozens of unnecessary rebuilds or simply don't work > > at all because someone wanted to avoid those rebuilds. > > Is this anything that won't be solved subslot dictionaries as suggested in > bug 462138? Maybe. Depends on whether developers will be able to spend their time keeping all those dictionaries up-to-date. That proposal is between ridiculous and insane from a wider point-of-view. Then we'd need USE-conditional subslots. Plus dynamic subslots, as people already suggested. Some special handling for virtuals. And we end up having 10 pages of text about subslots. And even with all that, some people like me will just disable them. Just because I want to control myself when packages are being rebuilt instead of having every world update bloated with rebuilds.
Instead of subslot dictionaries couldn't we create some kind of virtuals for libpoppler-{cpp,glib,qt4}? These would have SLOT="0/${SOVERSION}" and depend on app-text/poppler:=. These could be bumped whenever the SOVERSION in poppler changes.
(In reply to comment #36) > Instead of subslot dictionaries couldn't we create some kind of virtuals for > libpoppler-{cpp,glib,qt4}? These would have SLOT="0/${SOVERSION}" and depend > on app-text/poppler:=. These could be bumped whenever the SOVERSION in > poppler changes. That should work, but you'll have to specify the deps of the virtuals so that they only match the appropriate range of poppler versions, and I don't know how manageable that will be. Maybe a range of sub-slots will be useful, like this: || ( app-text/poppler:0/35 app-text/poppler:0/36 app-text/poppler:0/37 )
(In reply to comment #37) > (In reply to comment #36) > > Instead of subslot dictionaries couldn't we create some kind of virtuals for > > libpoppler-{cpp,glib,qt4}? These would have SLOT="0/${SOVERSION}" and depend > > on app-text/poppler:=. These could be bumped whenever the SOVERSION in > > poppler changes. > > That should work, but you'll have to specify the deps of the virtuals so > that they only match the appropriate range of poppler versions, and I don't > know how manageable that will be. Maybe a range of sub-slots will be useful, > like this: > > || ( app-text/poppler:0/35 app-text/poppler:0/36 app-text/poppler:0/37 ) Per the PMS, you'd have to revbump the virtual each time you add a new versions to the dep. Otherwise, non-portage PMs will refuse to ever update poppler...
(In reply to comment #37) > That should work, but you'll have to specify the deps of the virtuals so > that they only match the appropriate range of poppler versions, and I don't > know how manageable that will be. Maybe a range of sub-slots will be useful, > like this: > > || ( app-text/poppler:0/35 app-text/poppler:0/36 app-text/poppler:0/37 ) I was more thinking about a virtual/poppler-glib, which get bumped every time poppler has new release, so it would depend on ~app-text/poppler-${PV}. The only thing, which needs attention is its subslot, but this could be checked in pkg_postinst() with [[ -e ${EPREFIX}/usr/$(get_libdir)/libpoppler-glib$(libname ${SOVERION}) ]] || die "Oh no, upstream changed the so version of libpoppler-glib, come and fix me."
(In reply to comment #39) Sounds good to me.
Chaos. Add ruby@ again when there is a tl;dr of what you actually want
(In reply to comment #39) > (In reply to comment #37) > > That should work, but you'll have to specify the deps of the virtuals so > > that they only match the appropriate range of poppler versions, and I don't > > know how manageable that will be. Maybe a range of sub-slots will be useful, > > like this: > > > > || ( app-text/poppler:0/35 app-text/poppler:0/36 app-text/poppler:0/37 ) > > I was more thinking about a virtual/poppler-glib, which get bumped every > time poppler has new release, so it would depend on ~app-text/poppler-${PV}. > The only thing, which needs attention is its subslot, but this could be > checked in pkg_postinst() with > [[ -e ${EPREFIX}/usr/$(get_libdir)/libpoppler-glib$(libname ${SOVERION}) ]] > || die "Oh no, upstream changed the so version of libpoppler-glib, come and > fix me." Any problem with poppler using this approach?
Yes, not worth the effort. If you wish to have those subslot/virtual masturbations implemented, I won't interfere (and I'll remove myself as a maintainer from poppler package).
(In reply to comment #43) > Yes, not worth the effort. If you wish to have those subslot/virtual > masturbations implemented, I won't interfere (and I'll remove myself as a > maintainer from poppler package). As portage team doesn't want to enable preserve-lib feature by default in stable, we need to reach a solution: 1. They don't enable it because preserving libs without re-emerging packages as soon as possible could lead to problems like conflicting symbols being loaded. Then, portage team is expecting for subslots to be widely used before enabling this feature by default. 2. Some maintainers, like you, tell people to enable that feature and be done with it -> but we need to clearly merge positions as this is contradictory. I see two options: 1. The virtual/ approach and using subslots for "soname version bumps" 2. Change portage to force "emerge @preserved-rebuild" as soon as possible (I think I suggested that to dev-portage team some weeks ago but couldn't find the comment)
(In reply to comment #44) > (In reply to comment #43) > > Yes, not worth the effort. If you wish to have those subslot/virtual > > masturbations implemented, I won't interfere (and I'll remove myself as a > > maintainer from poppler package). > > As portage team doesn't want to enable preserve-lib feature by default in > stable, we need to reach a solution: > 1. They don't enable it because preserving libs without re-emerging packages > as soon as possible could lead to problems like conflicting symbols being > loaded. Then, portage team is expecting for subslots to be widely used > before enabling this feature by default. > 2. Some maintainers, like you, tell people to enable that feature and be > done with it -> but we need to clearly merge positions as this is > contradictory. > > I see two options: > 1. The virtual/ approach and using subslots for "soname version bumps" > 2. Change portage to force "emerge @preserved-rebuild" as soon as possible > (I think I suggested that to dev-portage team some weeks ago but couldn't > find the comment) Actually there is one other: 3. Use := in every app-text/poppler dependencies, where poppler libraries are used. For packages, which only depend on libpoppler-{cpp,glib,qt4}, we will get some extra unneeded rebuilds, but this is still an improvement over the current situation, where packages might break during a poopler update.
(In reply to comment #45) > (In reply to comment #44) > > I see two options: > > 1. The virtual/ approach and using subslots for "soname version bumps" > > 2. Change portage to force "emerge @preserved-rebuild" as soon as possible > > (I think I suggested that to dev-portage team some weeks ago but couldn't > > find the comment) > Actually there is one other: > 3. Use := in every app-text/poppler dependencies, where poppler libraries > are used. For packages, which only depend on libpoppler-{cpp,glib,qt4}, we > will get some extra unneeded rebuilds, but this is still an improvement over > the current situation, where packages might break during a poopler update. Erm, 'some'. Don't you know that when you force a lot unneeded rebuilds you simply make users work-around/disable the option and replace partial fix with no fix?
(In reply to comment #46) > (In reply to comment #45) > > (In reply to comment #44) > > > I see two options: > > > 1. The virtual/ approach and using subslots for "soname version bumps" > > > 2. Change portage to force "emerge @preserved-rebuild" as soon as possible > > > (I think I suggested that to dev-portage team some weeks ago but couldn't > > > find the comment) > > Actually there is one other: > > 3. Use := in every app-text/poppler dependencies, where poppler libraries > > are used. For packages, which only depend on libpoppler-{cpp,glib,qt4}, we > > will get some extra unneeded rebuilds, but this is still an improvement over > > the current situation, where packages might break during a poopler update. > > Erm, 'some'. Don't you know that when you force a lot unneeded rebuilds you > simply make users work-around/disable the option and replace partial fix > with no fix? The definition of some: "being an unknown, undetermined, or unspecified unit or thing". And that is exactly, what I meant, I don't known how many unneeded rebuilds this will trigger. And I, personally, also don't like this solution, which is why I suggested 1., but 3. might be still better than losing a poppler maintainer.
I suggest that packages using libpoppler-cpp.so, libpoppler-glib.so or libpoppler-qt4.so simply wait with using slot operator dependencies for poppler until a future EAPI provides subslot dictionaries or an alternative solution.
(In reply to comment #48) > I suggest that packages using libpoppler-cpp.so, libpoppler-glib.so or > libpoppler-qt4.so simply wait with using slot operator dependencies for > poppler until a future EAPI provides subslot dictionaries or an alternative > solution. I agree, and this is what I have been doing with packages so far.
Please do not break poppler-9999 with these schemes. Thanks.
Anyway, looks like sabayon has ebuilds with splitting done: https://github.com/Sabayon/sabayon-distro/tree/master/app-text and it doesn't look to require any "magic" or unofficial patches to be applied :/ (looks like it's a matter of using different configure flags for each package)
(In reply to Pacho Ramos from comment #51) > Anyway, looks like sabayon has ebuilds with splitting done: > https://github.com/Sabayon/sabayon-distro/tree/master/app-text Because they're a binary distro. We have useflags for that. It really isn't worth the trouble for such a small package. (I'm a former maintainer of the package.)
Closing since this bug has reached the status "CONFIRMED RAMBLING POINTLESS"
