| View previous topic :: View next topic |
| Author |
Message |
Superfox_il_Volpone
n00b
Joined: 14 Aug 2012
Posts: 47
|
 Posted: Sat Nov 10, 2012 9:27 am Post subject: boost libs |
 |
|
Hi,
in the last update of the environment I lost boost 1.48, obtained through the single shot =dev-libs/boost-1.48. I was keeping that version for development purposes. I cannot find it anymore in the emerge repository. Now, the update of environment asks to pass to boost 1-52 and to remove eselect-boost:
| Code: |
[ebuild U ~] dev-libs/boost-1.52.0-r1 [1.49.0-r1] USE="python threads%* -debug -doc -icu -mpi -static-libs -tools (-eselect%*) (-test%)" 0 kB
[uninstall ] app-admin/eselect-boost-0.4
[blocks b ] app-admin/eselect-boost ("app-admin/eselect-boost" is blocking dev-libs/boost-1.52.0-r1)
|
I guess gentoo developers removed the feature to keep more boost versions? What should I have done to avoid the unmerging of that specific version? To maintain a specific library, do I have to manually install it in a home prefix?
Regards
- s.fox |
|
| Back to top |
|
 |
phalaxy
Tux's lil' helper
Joined: 12 Aug 2008
Posts: 120
|
| Posted: Sat Nov 10, 2012 10:02 am Post subject: |
|
|
hi,
| Quote: | | To maintain a specific library, do I have to manually install it in a home prefix? |
better it is ... not comfortable, but possible
by the way my own opinion : damm boost devs - they did break their own api again WITHOUT changing the major version number from 1.x.x to 2.x.x
_________________
Gigabyte P43-ES3G Rev. 1.0 Mainboard Ver. F14 Bios
Intel Pentium E6300 (2x 2,8 Ghz)
8GB RAM (2x 4GB DDR2-800)
Sapphire AMD Radeon R7 240 PCIe 4GB VRAM
Gentoo Linux ~amd64 multilib
SWAP??? Are you kidding me?  |
|
| Back to top |
|
|
VoidMage
Watchman
Joined: 14 Oct 2006
Posts: 6196
|
| Posted: Sat Nov 10, 2012 2:25 pm Post subject: |
|
|
| Well, in this case (at least according to a post on gentoo-dev), it's glibc that started to use a value in 2.16, that somewhere deep down boost also used. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21595
|
| Posted: Sat Nov 10, 2012 4:21 pm Post subject: Re: boost libs |
|
|
| Superfox_il_Volpone wrote: | Hi,
in the last update of the environment I lost boost 1.48, obtained through the single shot =dev-libs/boost-1.48. I was keeping that version for development purposes. I cannot find it anymore in the emerge repository. Now, the update of environment asks to pass to boost 1-52 and to remove eselect-boost:
| Code: |
[ebuild U ~] dev-libs/boost-1.52.0-r1 [1.49.0-r1] USE="python threads%* -debug -doc -icu -mpi -static-libs -tools (-eselect%*) (-test%)" 0 kB
[uninstall ] app-admin/eselect-boost-0.4
[blocks b ] app-admin/eselect-boost ("app-admin/eselect-boost" is blocking dev-libs/boost-1.52.0-r1)
|
I guess gentoo developers removed the feature to keep more boost versions? What should I have done to avoid the unmerging of that specific version? To maintain a specific library, do I have to manually install it in a home prefix? |
Could you explain why you want to maintain an obsolete version? Staying on a legacy version indefinitely is asking for trouble. Eventually, something will change in an incompatible way, and then the maintainers must either remove the obsolete version or spend effort modifying it to adjust for the incompatible change. As VoidMage notes, new versions of glibc interfere with building old versions of Boost. New versions of Boost have already been adjusted to work properly.
| phalaxy wrote: | | by the way my own opinion : damm boost devs - they did break their own api again WITHOUT changing the major version number from 1.x.x to 2.x.x |
Changing the major version would not help you. The only solutions are either to support slotted installs or to release transition versions which support both the old and new API. Gentoo tried using slotted installs and it caused significant work for questionable gain. |
|
| Back to top |
|
|
Superfox_il_Volpone
n00b
Joined: 14 Aug 2012
Posts: 47
|
| Posted: Sat Nov 10, 2012 9:31 pm Post subject: Re: boost libs |
|
|
| Hu wrote: | | Could you explain why you want to maintain an obsolete version? |
| Superfox_il_Volpone wrote: | | I was keeping that version for development purposes. |
what the hell guys, it gets frustrating when the system does not behave as you would have figured out. If someone wants to install a specific program, that is slotted, he will reasonable expect that the system, for no reason would ever never whatever change, nor delete it. It could be buddy, dangerous, a symptom of masochism, the program may even create a large black hole sucking all the universe inside. It is not your business, leave it there as it is.
regards
s.fox |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21595
|
| Posted: Sat Nov 10, 2012 10:06 pm Post subject: |
|
|
| Though the developers removed it from the tree, the package manager left it on the system until you removed it. I saw your initial statement that you were keeping it for "development purposes," but I do not understand why you think that keeping an arbitrary obsolete version, which cannot be rebuilt using newer tools, is a good idea. If you are developing code that uses Boost, you should upgrade to the new version. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Nov 10, 2012 10:24 pm Post subject: |
|
|
sfox,
I agree with you that it should not have suddenly disappeared like that. But it has. Unfortunately I can only see 1.46 on the official tinderbox and 1.35(!) on Patrick's binhost which is usually more up to date.
To avoid this kind of thing, I use FEATURES=buildpkg: I know it's no help now, but if you had it setup, you would have had a built binpkg for your system. I hope you can see how that might be useful in future.
I have boost-1.48.0-r2 and boost-1.49.0-r1 built for stable amd64 with USE: doc eselect icu mpi tools -debug -python -static-libs -test. But you need python, and don't have eg icu set. That's why buildpkg is so important.
What you can do now, is get the old ebuild out of the attic (bookmark that second link), and put it in a local overlay then just emerge it again, after masking the newer version. (You'll need to cd to dev-libs/boost and run repoman manifest.) You will also need things out of the files/ subdirectory as well: reading the ebuild and running repoman/ emerge will soon tell you what you're missing.
Obviously, if I were you, I'd set up buildpkg first ;-)
Good luck,
steveL. |
|
| Back to top |
|
|
phalaxy
Tux's lil' helper
Joined: 12 Aug 2008
Posts: 120
|
| Posted: Sun Nov 11, 2012 10:10 am Post subject: |
|
|
... or merging code from boost to your own project and never worry about boost bogus at all again, but you have maintain the boost code you use additionally to your own code. by this way you reduce external project depencies. your decision ...
_________________
Gigabyte P43-ES3G Rev. 1.0 Mainboard Ver. F14 Bios
Intel Pentium E6300 (2x 2,8 Ghz)
8GB RAM (2x 4GB DDR2-800)
Sapphire AMD Radeon R7 240 PCIe 4GB VRAM
Gentoo Linux ~amd64 multilib
SWAP??? Are you kidding me? |
|
| Back to top |
|
|
geki
Advocate
Joined: 13 May 2004
Posts: 2387
Location: Germania
|
| Posted: Sun Nov 11, 2012 4:09 pm Post subject: |
|
|
another possibility would be my overlay. I maintain boost slotted. I know it too well to keep old crap around. 
check my sig: split-boost
_________________
hear hear |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21595
|
| Posted: Sun Nov 11, 2012 4:22 pm Post subject: |
|
|
| phalaxy wrote: | | ... or merging code from boost to your own project and never worry about boost bogus at all again, but you have maintain the boost code you use additionally to your own code. by this way you reduce external project depencies. your decision ... |
This works, but is a great way to make package maintainers hate you. Bundled libraries are evil. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Nov 11, 2012 10:38 pm Post subject: |
|
|
| Hu wrote: | | phalaxy wrote: | | ... or merging code from boost to your own project and never worry about boost bogus at all again, but you have maintain the boost code you use additionally to your own code. by this way you reduce external project depencies. your decision ... |
This works, but is a great way to make package maintainers hate you. Bundled libraries are evil. |
I'm fairly sure I read on the dev ML during recent discussion about this change, that boost recommends you bundle its code. It was mentioned as one of the contributory factors, along with "no other distro keeps multiple versions."
I'm not really sure what I make of that: if there is an issue with two projects using different versions of boost, whereby a slotted library still might fail due to conflicting symbols, doesn't that apply equally if they're both bundling different versions? Or are the developers supposed to use it internally only: how do they ensure symbols still don't clash? Sounds like a nightmare to me. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21595
|
| Posted: Sun Nov 11, 2012 10:59 pm Post subject: |
|
|
Yes, some upstream projects recommend that you bundle them. This attitude seems to be more common in the projects where they dislike keeping API compatibility across releases.
For the header-only Boost libraries, bundling them is probably safe, but I still think it is a bad idea. For the libraries which also build a shared object, you are correct that there are substantial risks if the users of the libraries do not take special steps to hide the Boost symbols from other code. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Nov 19, 2012 9:34 am Post subject: |
|
|
| Hu wrote: | | Yes, some upstream projects recommend that you bundle them. This attitude seems to be more common in the projects where they dislike keeping API compatibility across releases. |
ABI compatibility (which requires API compatibility) is the crux.
| Quote: | | For the header-only Boost libraries, bundling them is probably safe, but I still think it is a bad idea. For the libraries which also build a shared object, you are correct that there are substantial risks if the users of the libraries do not take special steps to hide the Boost symbols from other code. |
And what about Boost itself recommending bundling of its code? |
|
| Back to top |
|
|
MustrumR
n00b
Joined: 15 Nov 2011
Posts: 71
Location: Right here
|
| Posted: Mon Nov 19, 2012 12:12 pm Post subject: |
|
|
| Bundling third-party code is wrong. It's like going back to a.out times, just a bit worse. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21595
|
| Posted: Tue Nov 20, 2012 2:22 am Post subject: |
|
|
| steveL wrote: | | Hu wrote: | | Yes, some upstream projects recommend that you bundle them. This attitude seems to be more common in the projects where they dislike keeping API compatibility across releases. |
ABI compatibility (which requires API compatibility) is the crux. |
As users, we care about whether the project retains ABI compatibility. For developers, they care mostly about API compatibility. For a developer, if the API remains compatible, asking the user to rebuild with the latest headers is easy, since it does not require the developer to modify the code to handle the different versions of the underlying library.
| steveL wrote: | | Quote: | | For the header-only Boost libraries, bundling them is probably safe, but I still think it is a bad idea. For the libraries which also build a shared object, you are correct that there are substantial risks if the users of the libraries do not take special steps to hide the Boost symbols from other code. |
And what about Boost itself recommending bundling of its code? |
Could you rephrase the question? I stand by my statement that I dislike bundling, but that in some cases you can get away with it. That statement is independent of whether the project being bundled advocates bundling, because the statement is predicated on the probability that the bundling will cause more problems than it solves. Although the library project can take steps to make it easier for the bundler to avoid problems, the only way to be completely safe is to ensure that all programs using the library code load exactly the same copy of the supporting library. This is easiest when bundling does not occur. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Nov 22, 2012 7:26 am Post subject: |
|
|
| Hu wrote: | | steveL wrote: | | ABI compatibility (which requires API compatibility) is the crux. |
As users, we care about whether the project retains ABI compatibility. For developers, they care mostly about API compatibility. For a developer, if the API remains compatible, asking the user to rebuild with the latest headers is easy, since it does not require the developer to modify the code to handle the different versions of the underlying library. |
I know full well what developers are like (and also the difference with a developer who cares about their users, who will care about ABI.)
The point I was making was in the context of your remark that "This attitude seems to be more common in the projects where they dislike keeping API compatibility across releases." I was saying that actually it's more common where they dislike monitoring ABI compatibility, which yes is because of changes in API, but not necessary loss of API compatibility.
For instance, changing a function to take a long parameter instead of an int, maintains API compatibility in that existing code that calls it with an int argument, will still work with that "easy rebuild" against new headers. It totally screws ABI compatibility though, and requires a change in symbol and/or major version, or a different function.
This is why you get projects like udev or systemd going through frequent major version changes, apparently emulating the kernel, badly. They forget that the kernel only has a flexible attitude to internal interfaces: externally exported interfaces are pretty much set in stone. An example would be epoll_create and epoll_create1 (see man epoll_create.)
| Quote: | | steveL wrote: | | Quote: | | For the header-only Boost libraries, bundling them is probably safe, but I still think it is a bad idea. For the libraries which also build a shared object, you are correct that there are substantial risks if the users of the libraries do not take special steps to hide the Boost symbols from other code. |
And what about Boost itself recommending bundling of its code? |
Could you rephrase the question? I stand by my statement that I dislike bundling, but that in some cases you can get away with it. That statement is independent of whether the project being bundled advocates bundling, because the statement is predicated on the probability that the bundling will cause more problems than it solves. Although the library project can take steps to make it easier for the bundler to avoid problems, the only way to be completely safe is to ensure that all programs using the library code load exactly the same copy of the supporting library. This is easiest when bundling does not occur. |
Oh I totally agree with you about bundling libraries. My point was that boost is still recommending developers bundle their code, and especially in the case of headers that could cause an issue, if your goal is to ensure all packages use the same centrally managed version. A properly setup build-system should cover that, but upstream developers might not think it a concern, given that boost has recommended bundling, which leaves more education needing to be done by Gentoo devs, usually by having to provide patches which also means more work. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
