Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 462020 - app-text/poppler - use EAPI=5 subslot operator := in reverse dependencies
Summary: app-text/poppler - use EAPI=5 subslot operator := in reverse dependencies
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Gentoo KDE team
URL:
Whiteboard:
Keywords:
Depends on: 462074
Blocks:
  Show dependency tree
 
Reported: 2013-03-17 12:06 UTC by Andreas K. Hüttel
Modified: 2014-04-27 08:20 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas K. Hüttel archtester gentoo-dev 2013-03-17 12:06:47 UTC
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
Comment 1 Justin Lecher (RETIRED) gentoo-dev 2013-03-17 12:28:33 UTC
(In reply to comment #0)
> app-office/texmaker
> app-office/texstudio

Fixed.
Comment 2 Andreas K. Hüttel archtester gentoo-dev 2013-03-17 12:35:27 UTC
(In reply to comment #0)

> app-text/kbibtex
> app-text/pdf2oo
> app-text/xournal
> sci-electronics/cirkuit

Fixed.
Comment 3 Samuli Suominen (RETIRED) gentoo-dev 2013-03-17 13:23:30 UTC
(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@
Comment 4 Andreas K. Hüttel archtester gentoo-dev 2013-03-17 15:44:23 UTC
> net-print/cups (does not link to poppler)
> net-print/cups-filters

Fixed
Comment 5 Andreas K. Hüttel archtester gentoo-dev 2013-03-17 16:15:27 UTC
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
Comment 6 Mike Gilbert gentoo-dev 2013-03-17 16:18:44 UTC
matplotlib does not appear to link with poppler -- is there any reason to rebuild it?
Comment 7 Andreas K. Hüttel archtester gentoo-dev 2013-03-17 16:24:06 UTC
(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.)
Comment 8 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-03-17 17:08:48 UTC
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?
Comment 9 Sergey Popov gentoo-dev 2013-03-17 17:13:07 UTC
app-text/yagf - done
Comment 10 Mike Gilbert gentoo-dev 2013-03-17 17:20:17 UTC
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.
Comment 11 Sébastien Fabbro (RETIRED) gentoo-dev 2013-03-17 17:38:48 UTC
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
Comment 12 Maciej Mrozowski gentoo-dev 2013-03-18 01:14:24 UTC
(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!
Comment 13 Mike Gilbert gentoo-dev 2013-03-18 01:42:44 UTC
(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.
Comment 14 Arfrever Frehtes Taifersar Arahesis 2013-03-18 04:20:55 UTC
Bug #462138 suggests proper solution for future EAPIs.
Comment 15 Andreas K. Hüttel archtester gentoo-dev 2013-03-18 08:15:03 UTC
(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...
Comment 16 Michael Palimaka (kensington) gentoo-dev 2013-03-18 10:00:33 UTC
(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ł.
Comment 17 Michael Palimaka (kensington) gentoo-dev 2013-03-18 11:08:13 UTC
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).
Comment 18 Pacho Ramos gentoo-dev 2013-03-18 11:43:22 UTC
This could also be solved by splitting poppler, but not sure if it would be feasible :S
Comment 19 Christian Faulhammer (RETIRED) gentoo-dev 2013-03-18 22:14:55 UTC
I go with the subslot operator on

> mail-client/claws-mail-pdf-viewer
Comment 20 Maciej Mrozowski gentoo-dev 2013-03-18 23:13:57 UTC
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.
Comment 21 Pacho Ramos gentoo-dev 2013-03-19 21:26:33 UTC
(In reply to comment #20)
[...] 
> Btw, poppler will not be split (again). Been there, done that.

Why was it unsplitted? Thanks for the information :)
Comment 22 Sergey Popov gentoo-dev 2013-03-20 07:15:43 UTC
(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)
Comment 23 Maciej Mrozowski gentoo-dev 2013-03-21 00:39:52 UTC
(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
Comment 24 Pacho Ramos gentoo-dev 2013-03-21 20:24:37 UTC
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?
Comment 25 Maciej Mrozowski gentoo-dev 2013-03-26 22:29:34 UTC
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™.
Comment 26 Pacho Ramos gentoo-dev 2013-03-27 09:08:40 UTC
(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)
Comment 27 Zac Medico gentoo-dev 2013-03-27 15:06:03 UTC
(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.
Comment 28 Pacho Ramos gentoo-dev 2013-03-27 18:33:25 UTC
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
Comment 29 Zac Medico gentoo-dev 2013-03-27 18:40:22 UTC
(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).
Comment 30 Pacho Ramos gentoo-dev 2013-03-27 18:57:21 UTC
And what about doing that automatic "emerge @preserved-rebuild" run only when merge fails and "--keep-going" is used?
Comment 31 Zac Medico gentoo-dev 2013-03-27 19:05:35 UTC
(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.
Comment 32 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-03-27 19:35:27 UTC
(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.
Comment 33 Zac Medico gentoo-dev 2013-03-27 19:41:56 UTC
(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?
Comment 34 Pacho Ramos gentoo-dev 2013-03-27 19:47:35 UTC
(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 :|
Comment 35 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-03-27 20:07:49 UTC
(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.
Comment 36 Christoph Junghans gentoo-dev 2013-03-27 21:55:05 UTC
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.
Comment 37 Zac Medico gentoo-dev 2013-03-27 23:11:19 UTC
(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 )
Comment 38 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-03-28 15:35:17 UTC
(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...
Comment 39 Christoph Junghans gentoo-dev 2013-03-28 17:01:18 UTC
(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."
Comment 40 Zac Medico gentoo-dev 2013-03-28 17:13:31 UTC
(In reply to comment #39)
Sounds good to me.
Comment 41 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2013-03-28 21:58:44 UTC
Chaos. Add ruby@ again when there is a tl;dr of what you actually want
Comment 42 Pacho Ramos gentoo-dev 2013-05-01 09:00:06 UTC
(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?
Comment 43 Maciej Mrozowski gentoo-dev 2013-05-01 14:16:46 UTC
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).
Comment 44 Pacho Ramos gentoo-dev 2013-05-01 14:27:56 UTC
(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)
Comment 45 Christoph Junghans gentoo-dev 2013-05-01 14:52:01 UTC
(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.
Comment 46 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-05-01 15:12:09 UTC
(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?
Comment 47 Christoph Junghans gentoo-dev 2013-05-01 15:25:30 UTC
(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.
Comment 48 Arfrever Frehtes Taifersar Arahesis 2013-05-01 23:45:47 UTC
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.
Comment 49 Michael Palimaka (kensington) gentoo-dev 2013-05-02 15:37:57 UTC
(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.
Comment 50 James Cloos 2013-05-02 19:51:04 UTC
Please do not break poppler-9999 with these schemes.

Thanks.
Comment 51 Pacho Ramos gentoo-dev 2013-06-04 18:56:10 UTC
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)
Comment 52 Ben de Groot (RETIRED) gentoo-dev 2014-03-21 11:10:50 UTC
(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.)
Comment 53 Andreas K. Hüttel archtester gentoo-dev 2014-04-26 23:21:54 UTC
Closing since this bug has reached the status "CONFIRMED RAMBLING POINTLESS"