Summary: | app-office/libreoffice-bin - Please recompile against the latest stable dev-util/boost-1.52.0-r6 and app-text/poppler-0.22.5 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Anton Bolshakov <anton.bugs> |
Component: | Current packages | Assignee: | Andreas K. Hüttel <dilfridge> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | admwiggin, beschindler, c.affolter, carlo.dormeletti, flyser42, gentoo, gentoo, hrabe, jesse, johnnybit, marsicanbear, mf-gentoo-bugzilla, mihais23, njsg, office, orodruinlair, pinkbyte, quasi, raphael.droz+floss, redneb, rossi.f, Sergiy.Borodych, yac |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://forums.gentoo.org/viewtopic-t-970672.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 489566 | ||
Bug Blocks: | |||
Attachments: | libreoffice-bin-4.0.4.2-r1.ebuild |
Description
Anton Bolshakov
2013-09-21 14:28:26 UTC
Additionally, app-text/poppler-0.22.5:0/37 is now stable, while libreoffice-bin is compiled against :0/35. Yes we know. We will stabilize a new version of libreoffice soon, and afterwards generate a new libreoffice-bin. Expect it in roughly 2 weeks. *** Bug 485380 has been marked as a duplicate of this bug. *** (In reply to Andreas K. Hüttel from comment #2) > Yes we know. I want to know that this is NOT cool. Libreoffice is a very important package for many users and many of us not ready to compile it for 3 hours. Is any way to prevent such situations in future?.. Like, can't you build it in advance and stabilize *together* with dependences?.. s/to know/to let you know/ Well we want to be sure the combination really works... and that involves testing. No point in stabilizing libreoffice and generating libreoffice-bin when immediately afterwards something else is broken. Anyway, your libreoffice-bin should still work fine because of such great features as preserved-libs, and noone forces you to upgrade the libraries immediately. See also http://forums.gentoo.org/viewtopic-t-970672.html (In reply to Andreas K. Hüttel from comment #6) > and noone forces you to upgrade the libraries > immediately. > > See also http://forums.gentoo.org/viewtopic-t-970672.html <offtopic> well, just FYI: It just happened that I'm installing a *new* gentoo desktop for a friend of mine. I explained to him how cool gentoo is, and all that. Now, I need to explain him all these tricks/workarounds - mask libraries, follow up with bug reports, read forums, or compile for 3 hours. Do you think he is getting exciting about Gentoo??? That's a rhetorical question. </offtopic> (In reply to Andreas K. Hüttel from comment #6) > > See also http://forums.gentoo.org/viewtopic-t-970672.html Thanks for the link. So why not issuing a "news" item whenever something like this might happen? That may simply tell *-bin user to temporarily mask the libs while waiting for a new bin release... (In reply to sphakka from comment #8) > (In reply to Andreas K. Hüttel from comment #6) > > > > See also http://forums.gentoo.org/viewtopic-t-970672.html > > Thanks for the link. So why not issuing a "news" item whenever something > like this might happen? That may simply tell *-bin user to temporarily mask > the libs while waiting for a new bin release... Because that's not the way how it supposed to be. The proper way is to create a -r1 in *advance* and stabilize the whole set at the same time. That's how it works with xorg* stuff, for example. The stable user suppose to run "emerge -DNu world" smoothly. (In reply to Andreas K. Hüttel from comment #6) > Anyway, your libreoffice-bin should still work fine because of such great > features as preserved-libs, and noone forces you to upgrade the libraries > immediately. Boost was stabilized for security issue, so, it's some kind of good forcing, i think :-) And yes, hit this bug too *** Bug 485874 has been marked as a duplicate of this bug. *** So, if I choose to do nothing, updates pile up behind this one as they are released into stable, since it blocks world updates entirely. Some of those may or may not be other security updates. Seems a little narrow to say this is a good move overall. :/ Cheers. (In reply to Andreas K. Hüttel from comment #6) > Well we want to be sure the combination really works... and that involves > testing. No point in stabilizing libreoffice and generating libreoffice-bin > when immediately afterwards something else is broken. > > Anyway, your libreoffice-bin should still work fine because of such great > features as preserved-libs, and noone forces you to upgrade the libraries > immediately. The problem here is that when you `emerge -uaNDv wordl` you will get blockage like dev-libs/boost:0 (dev-libs/boost-1.52.0-r6::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (dev-libs/boost-1.49.0-r2::gentoo, installed) pulled in by dev-libs/boost:0/0= required by (dev-cpp/libcmis-0.3.1::gentoo, installed) dev-libs/boost:0/0= required by (dev-libs/liborcus-0.3.0::gentoo, installed) =dev-libs/boost-1.49* required by (app-office/libreoffice-bin-4.0.4.2::gentoo, installed) and you are screwed. welp, not entirely screwed. >=dev-libs/boost-1.50 >app-text/poppler-0.22.2-r2 in package.mask did it for me. (In reply to Jesse Adelman from comment #13) > So, if I choose to do nothing, updates pile up behind this one as they are > released into stable, since it blocks world updates entirely. You can mask those temporarily (see above). May be a more clear solution here would be to bundle libraries in libreoffice-bin? (I mean bundle the latest stable at the moment of compiling) The fact that libraries are not bundled does not improve security here, even worse, it leads to impossibility to update them to allow other packages use newer version in case of security issues. (In reply to Jauhien Piatlicki from comment #16) > May be a more clear solution here would be to bundle libraries in > libreoffice-bin? (I mean bundle the latest stable at the moment of compiling) > > The fact that libraries are not bundled does not improve security here, even > worse, it leads to impossibility to update them to allow other packages use > newer version in case of security issues. It would probably add the work of 1. bundling the libs. 2.1. monitoring the bundled libs, so users can be informed there are security issues. Which we currently get for free with a little work for the user (adding a few lines to package.mask if you don't care / uninstall or build from source if you do) 2.2. or not having the security issue notification. So, I couldn't wait anymore for a new compiled version of libreoffice-bin. Actually, I'm glad to say that libreoffice-bin-4.0.4.2 will work just fine with the new versions of boost and poppler without recompiling. If just changed the dependency in the ebuild and now everything is working. Created attachment 360926 [details]
libreoffice-bin-4.0.4.2-r1.ebuild
ebuild with modified dependencies to install the stable libreoffice-bin in combination with the latest stable versions of boost and poppler
*** Bug 489020 has been marked as a duplicate of this bug. *** Libreoffice might be the single most important application on many systems, but it has been broken for over a month now even though a solution has been known for the entire time (and actually was know before it even broke). Please release a fix a.s.a.p. (In reply to Jeroen Roos from comment #21) > Libreoffice might be the single most important application on many systems, > but it has been broken for over a month now even though a solution has been > known for the entire time (and actually was know before it even broke). > Please release a fix a.s.a.p. Install app-office/libreoffice? (In reply to Nuno J. Silva from comment #22) > Install app-office/libreoffice? mask app-office/libreoffice-bin or drop the stable keywords. (In reply to Anton Bolshakov from comment #23) > (In reply to Nuno J. Silva from comment #22) > > Install app-office/libreoffice? > > mask app-office/libreoffice-bin or drop the stable keywords. Totally agree. If that package is in the stable tree, it needs to play well with other stable packages. If there is no manpower to maintain it, let's mask / remove / keyword it, but if it stays there, it really should be fixed. I hope it will get a bump so that people with older hardware can install libreoffice on gentoo without spending days in compilation time. Thanks to whoever is working on this. (In reply to bartoz from comment #24) > (In reply to Anton Bolshakov from comment #23) > > (In reply to Nuno J. Silva from comment #22) > > > Install app-office/libreoffice? > > > > mask app-office/libreoffice-bin or drop the stable keywords. > > Totally agree. > If that package is in the stable tree, it needs to play well with other > stable packages. > If there is no manpower to maintain it, let's mask / remove / keyword it, > but if it stays there, it really should be fixed. > > I hope it will get a bump so that people with older hardware can install > libreoffice on gentoo without spending days in compilation time. Thanks to > whoever is working on this. Why exactly can't you install the current libreoffice-bin in your system? The current ebuild, the one which is on the tree, plays well with other stable packages, just not with the newest stable versions of some libraries. Please follow the steps in comment #15. (In reply to Nuno J. Silva from comment #25) > (In reply to bartoz from comment #24) > > (In reply to Anton Bolshakov from comment #23) > > > (In reply to Nuno J. Silva from comment #22) > > > > Install app-office/libreoffice? > > > > > > mask app-office/libreoffice-bin or drop the stable keywords. > > > > Totally agree. > > If that package is in the stable tree, it needs to play well with other > > stable packages. > > If there is no manpower to maintain it, let's mask / remove / keyword it, > > but if it stays there, it really should be fixed. > > > > I hope it will get a bump so that people with older hardware can install > > libreoffice on gentoo without spending days in compilation time. Thanks to > > whoever is working on this. > > Why exactly can't you install the current libreoffice-bin in your system? > The current ebuild, the one which is on the tree, plays well with other > stable packages, just not with the newest stable versions of some libraries. > > Please follow the steps in comment #15. That's exactly what I have now. It just seems wrong that since app-office/libreoffice-4.1.2.3 has been stable for a while, we still do not have app-office/libreoffice-bin-4.1.2.3, which, if I understand correctly, would work well with all the newest stable packages. (In reply to bartoz from comment #26) > (In reply to Nuno J. Silva from comment #25) > > Why exactly can't you install the current libreoffice-bin in your system? > > The current ebuild, the one which is on the tree, plays well with other > > stable packages, just not with the newest stable versions of some libraries. > > > > Please follow the steps in comment #15. > > That's exactly what I have now. > It just seems wrong that since app-office/libreoffice-4.1.2.3 has been > stable for a while, we still do not have app-office/libreoffice-bin-4.1.2.3, > which, if I understand correctly, would work well with all the newest stable > packages. Ok, I will run an emerge --sync later and see if there is some new conflict, because I *did* install libreoffice-bin with these lines in package.mask, and it is working so far. libreoffice-bin will always be a difficult package. It has to be built and tested on the gentoo side, and I don't even know how does it work so well, given that it uses C++ libraries. I would definitely *not* try the ideas above about removing the dependencies on lower versions of poppler and boost. These dependencies are there for a reason. (In reply to Nuno J. Silva from comment #27) > (In reply to bartoz from comment #26) > > (In reply to Nuno J. Silva from comment #25) > > > Why exactly can't you install the current libreoffice-bin in your system? > > > The current ebuild, the one which is on the tree, plays well with other > > > stable packages, just not with the newest stable versions of some libraries. > > > > > > Please follow the steps in comment #15. > > > > That's exactly what I have now. > > It just seems wrong that since app-office/libreoffice-4.1.2.3 has been > > stable for a while, we still do not have app-office/libreoffice-bin-4.1.2.3, > > which, if I understand correctly, would work well with all the newest stable > > packages. > > Ok, I will run an emerge --sync later and see if there is some new conflict, > because I *did* install libreoffice-bin with these lines in package.mask, > and it is working so far. Great, thank you. > > libreoffice-bin will always be a difficult package. It has to be built and > tested on the gentoo side, and I don't even know how does it work so well, > given that it uses C++ libraries. Yeah, I see that. On that side, thanks to everyone who helps maintaining that package. I would definitely *not* try the ideas > above about removing the dependencies on lower versions of poppler and > boost. These dependencies are there for a reason. Sure. (In reply to bartoz from comment #28) > (In reply to Nuno J. Silva from comment #27) > > > > Ok, I will run an emerge --sync later and see if there is some new conflict, > > because I *did* install libreoffice-bin with these lines in package.mask, > > and it is working so far. > > Great, thank you. Portage shows no conflicts, I can generate an emerge -av libreoffice-bin with no blockers or conflicts. All done. Please remember to remove any mask files again. [ebuild UD ] app-text/poppler-0.22.5:0/37 [ebuild UD ] dev-libs/icu-51.1:0/51.1 (In reply to Anton Bolshakov from comment #31) > [ebuild UD ] app-text/poppler-0.22.5:0/37 > [ebuild UD ] dev-libs/icu-51.1:0/51.1 Please don't reopen the old bugs. See bug 490114 instead. the root cause of this bug is not fixed so I'm reopening. I got tired hitting it again and again with each and every new release Don't reopen this. |