Summary: | app-text/dvipng-1.14 blocks app-text/texlive-2014 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas Beutin <tb> |
Component: | Current packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
texi2dvi-0-r1 ebuild patch
dvipng-1.15-r1 ebuild patch |
Description
Thomas Beutin
2015-08-27 13:51:09 UTC
You need to update *all* your tex-related packages at the same time to 2014. And try giving portage a large backtrack level so it can resolve all conflicts between dependencies. Something like "emerge -1 --update --deep --newuse --backtrack=30 dvipng texlive texlive-langgerman texlive-texinfo luatex". Add more ebuilds to the list if needed. Alternatively, "emerge -1 --deep --update --newuse --backtrack=30 @world" may do it. Even when i set " --backtrack=100" i run into trouble w/ app-text/dvipng: dev-libs/kpathsea:0 (dev-libs/kpathsea-6.1.0_p20120701:0/0::gentoo, installed) pulled in by dev-libs/kpathsea:0/0= required by (app-text/dvipng-1.15:0/0::gentoo, installed) ^^^^^ (dev-libs/kpathsea-6.2.0_p20140525:0/6.2.0::gentoo, ebuild scheduled for merge) pulled in by >=dev-libs/kpathsea-6.2.0 required by (app-text/texlive-core-2014-r4:0/0::gentoo, ebuild scheduled for merge) ^^ ^^^^^ (and 4 more with the same problem) (In reply to Thomas Beutin from comment #2) Interesting. The solution is to explicitly update kpathsea (add "=dev-libs/kpathsea-6.2.0_p20140525" to your "emerge -1" arguments), but portage should have been able to understand that automatically... CC-ing portage devs. Created attachment 410788 [details]
texi2dvi-0-r1 ebuild patch
# diff -ubB /usr/portage/virtual/texi2dvi/texi2dvi-0.ebuild /usr/local/portage/virtual/texi2dvi/texi2dvi-0-r1.ebuild
Since dev-texlive/texlive-texinfo-2012 is a stub anyway this can be removed from the ebuild
Created attachment 410794 [details, diff]
dvipng-1.15-r1 ebuild patch
diff -ubB /usr/portage/app-text/dvipng/dvipng-1.15.ebuild /usr/local/portage/app-text/dvipng/dvipng-1.15-r1.ebuild
After removing the trailing ':=' from "dev-libs/kpathsea" in RDEPEND "everything works fine for me"(tm).
I'm not too deep into ebuild conding, but IIRC the trailing ':=' requests any slot, but since dev-libs/kpathsea is not slotted this might be the bug.
But now dvipng links to the curent installed lib:
# ldd /usr/bin/dvipng | grep kpathsea
libkpathsea.so.6 => /usr/lib64/libkpathsea.so.6 (0x00007f88ffa00000)
ls /usr/lib64/libkpathsea.* | cat
/usr/lib64/libkpathsea.so
/usr/lib64/libkpathsea.so.6
/usr/lib64/libkpathsea.so.6.2.0
(In reply to Alexandre Rostovtsev from comment #3) > (In reply to Thomas Beutin from comment #2) > > Interesting. The solution is to explicitly update kpathsea (add > "=dev-libs/kpathsea-6.2.0_p20140525" to your "emerge -1" arguments), but > portage should have been able to understand that automatically... > > CC-ing portage devs. It's not recommended to do anything other than emerge -uD @world for updates, since that gives the dependency resolver as much freedom as possible. What generally fail to understand is that commands like 'emerge -pv1Nu app-text/dvipng' constrain the dependency resolver to *only* update dvipng, which means that the calculation is *intended* to fail if any other changes are required. (In reply to Zac Medico from comment #6) > It's not recommended to do anything other than emerge -uD @world for > updates, since that gives the dependency resolver as much freedom as > possible. What generally fail to understand is that commands like 'emerge > -pv1Nu app-text/dvipng' constrain the dependency resolver to *only* update > dvipng, which means that the calculation is *intended* to fail if any other > changes are required. Since this is a common problem, I've filed bug 559354 to add an emerge option which tells it to "update any packages necessary" (which --update does not do). (In reply to Zac Medico from comment #6) > (In reply to Alexandre Rostovtsev from comment #3) > > (In reply to Thomas Beutin from comment #2) > > > > Interesting. The solution is to explicitly update kpathsea (add > > "=dev-libs/kpathsea-6.2.0_p20140525" to your "emerge -1" arguments), but > > portage should have been able to understand that automatically... > > > > CC-ing portage devs. > > It's not recommended to do anything other than emerge -uD @world for > updates, since that gives the dependency resolver as much freedom as > possible. What generally fail to understand is that commands like 'emerge > -pv1Nu app-text/dvipng' constrain the dependency resolver to *only* update > dvipng, which means that the calculation is *intended* to fail if any other > changes are required. This would also update dev-libs/boost and dev-util/boost-build from ~1.55.0 to ~1.56.0 which is a no-go on my system. But maybe i've not fully understood the ebuild system by now... (In reply to Thomas Beutin from comment #8) > This would also update dev-libs/boost and dev-util/boost-build from ~1.55.0 > to ~1.56.0 which is a no-go on my system. But maybe i've not fully > understood the ebuild system by now... You can mask upgrades that you don't want in /etc/portage/package.mask. *** This bug has been marked as a duplicate of bug 543290 *** *** This bug has been marked as a duplicate of bug 290818 *** |