Re: [gentoo-dev] [RFC] Dropping slotted boost
Am Dienstag, den 30.10.2012, 22:48 -0700 schrieb Diego Elio Pettenò: On 30/10/2012 22:44, Tiziano Müller wrote: I agree. It really doesn't make sense to keep unbuildable stuff in the tree. The point of slotting it in the first place was also to force a rebuild of reverse dependencies to have them use newer boost (since at that time when boost slotting was introduced we had some API breakages occurring between versions). Now with the sub-slots we can simply use this feature to tell the PM to rebuild the stuff. Well, as long as the soname is correct (which it is), with preserved-rebuild (which is now available on ~arch Portage as well), this is basically already possible to some extent without even using subslots. Each new minor version bump (1.49 - 1.50) will orphan the 1.49 libraries, @preserved-rebuild will rebuild the linked packages. Of course for those that don't link to the objects, but only use the headers, the sub-slots make it possible as well. Didn't have @preserved-rebuild back then and I don't really consider this a feature (but that's just a side note). One reason for the slotting was also to give people developing code on Gentoo the chance to easily have multiple versions of boost in parallel (for testing, etc.). This was also the main reason to introduce eselect-boost (besides making the transition to slotted boost easier .. a transition which never really happened since everyone kept relying on eselect-boost). But that too stems from a time when boost got a release once a year, so by now slotting is really just a burden. Question is: do we want to keep the versioned soname scheme (which doesn't make much sense without the slotting) or not. I would like to see it removed together with the slotting. Concerning the maintenance: I'd prefer herdcpp/herd and nothing else. The reason for this is that boost is tied to the development of C++ itself pretty closely and we want that people who take care of boost have enough knowledge about C++ itself.. and then: why not share your knowledge by taking care of some other C++ packages as well.
[gentoo-dev] [RFC] Dropping slotted boost
Given the amount of headaches that Boost seems to give us all, now thanks to the recent changes even more because Gentoo's boost is different from all others and no upstream default check seem to work correctly with it, I'm questioning the usefulness of having it slotted. Among other things, with each GCC/GLIBC update all but a handful of slots are kept working; in this case I think most if not all 1.50 are broken. So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? Thanks, -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, 30 Oct 2012 11:30:16 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: Given the amount of headaches that Boost seems to give us all, now thanks to the recent changes even more because Gentoo's boost is different from all others and no upstream default check seem to work correctly with it, I'm questioning the usefulness of having it slotted. Could you elaborate on that? I don't remember having problems with boost.m4 or cmake's default checks unless I'm missing something which is obvious to you. So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, Oct 30, 2012 at 3:24 PM, Michał Górny mgo...@gentoo.org wrote: On Tue, 30 Oct 2012 11:30:16 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: Given the amount of headaches that Boost seems to give us all, now thanks to the recent changes even more because Gentoo's boost is different from all others and no upstream default check seem to work correctly with it, I'm questioning the usefulness of having it slotted. Could you elaborate on that? I don't remember having problems with boost.m4 or cmake's default checks unless I'm missing something which is obvious to you. So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? It's worth noting that Boost themselves recommend developers inline the code they want to use. I've never understood why Gentoo uses a separate ebuild for it. I mean, I can understand some efficiency gains from having a single compiled copy, but it shouldn't be surprising in the least when upstream makes breaking changes in the API. -- :wq
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 12:24, Michał Górny wrote: How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? How are you going to solve the problem that the packages that are not fixed to work with a new boost are not going to work anyway because boost.m4 will still get the latest one, and most of the old ones wouldn't work anyway because they are not compatible with the compiler/C library/whatever? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/12 21:24, Michał Górny wrote: On Tue, 30 Oct 2012 11:30:16 -0700 So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? That would be the job for the maintainers of the packages. If they don't fix it, they lastrite it. Simple as that. No reason to treat boost any different from, say, jpeg or libpng
Re: [gentoo-dev] [RFC] Dropping slotted boost
Dne Út 30. října 2012 20:24:26, Michał Górny napsal(a): On Tue, 30 Oct 2012 11:30:16 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: Given the amount of headaches that Boost seems to give us all, now thanks to the recent changes even more because Gentoo's boost is different from all others and no upstream default check seem to work correctly with it, I'm questioning the usefulness of having it slotted. Could you elaborate on that? I don't remember having problems with boost.m4 or cmake's default checks unless I'm missing something which is obvious to you. Michal, given my affiliation with libreoffice I am handling quite few sh*t about buildsystems there. Currently we have orcus/wps/visio and libreoffice itself checking for internal components of boost in the configure scripts. You basically want me to add 1 kB m4 file from some github site (aside from fact it is nicely licensed GPLv3) and change all those checks we have to confor with this m4 so they work again for Gentoo. Here let me put the emphasis on FOR GENTOO because no other distro on to this day had problem with the boost setup lo projects are using, and we include stuff like win and mac. My alternative for this work is to do this on gentoo side and add append cflags and libs in each pkg using the boost-utils eclass and again add more shit i have to maintain into each ebuild. So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? Simple, as any other lib, depend on older version and possibly port it forward. If that does not work then mask and wipe. Life goes on. Do we have at least some good use case on split boost requirement? Tomas
Re: [gentoo-dev] [RFC] Dropping slotted boost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/10/12 03:45 PM, Tomáš Chvátal wrote: Dne Út 30. října 2012 20:24:26, Michał Górny napsal(a): On Tue, 30 Oct 2012 11:30:16 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? Simple, as any other lib, depend on older version and possibly port it forward. If that does not work then mask and wipe. Life goes on. If we un-slot boost there won't be an 'older' version available on users systems anymore; when the new boost hits ~arch and then stable, all ~arch / stable rdeps will -need- to build against that version of boost, period (or be lastrite'd as ssuominen suggested) unless i'm missing your meaning here? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlCQMOQACgkQ2ugaI38ACPCGAwEAi1Oe50EPF87hI11hUVkovcvM xs/DOoDXKkuxArfdKjQA/0AFMkOhITgb1QcSwisO6jGREewZgUt/XKNnoRP2bx7q =u7CM -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, 30 Oct 2012 15:56:21 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/10/12 03:45 PM, Tomáš Chvátal wrote: Dne Út 30. října 2012 20:24:26, Michał Górny napsal(a): On Tue, 30 Oct 2012 11:30:16 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? Simple, as any other lib, depend on older version and possibly port it forward. If that does not work then mask and wipe. Life goes on. If we un-slot boost there won't be an 'older' version available on users systems anymore; when the new boost hits ~arch and then stable, all ~arch / stable rdeps will -need- to build against that version of boost, period (or be lastrite'd as ssuominen suggested) unless i'm missing your meaning here? a sane pm wont try to upgrade to version 5 if 5 is required by some package. +1 for unslotting
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/12 22:02, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/10/12 04:00 PM, Alexis Ballier wrote: On Tue, 30 Oct 2012 15:56:21 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/10/12 03:45 PM, Tomáš Chvátal wrote: Dne Út 30. října 2012 20:24:26, Michał Górny napsal(a): On Tue, 30 Oct 2012 11:30:16 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? Simple, as any other lib, depend on older version and possibly port it forward. If that does not work then mask and wipe. Life goes on. If we un-slot boost there won't be an 'older' version available on users systems anymore; when the new boost hits ~arch and then stable, all ~arch / stable rdeps will -need- to build against that version of boost, period (or be lastrite'd as ssuominen suggested) unless i'm missing your meaning here? a sane pm wont try to upgrade to version 5 if 5 is required by some package. +1 for unslotting ..until something else ~arch (or stable) in the tree -needs- =5 (and we only need one fairly common package for that to happen), and then it all falls apart with same-slot conflicts. the new boost will be p.masked for long as every package in tree has been fixed for it, or masked for lastrite the policy is same as for any other package, can't set dependencies on the same stabilization level that would cause same-slot conflicts so no problem there
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, 30 Oct 2012 12:32:57 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 30/10/2012 12:24, Michał Górny wrote: How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? How are you going to solve the problem that the packages that are not fixed to work with a new boost are not going to work anyway because boost.m4 will still get the latest one, and most of the old ones wouldn't work anyway because they are not compatible with the compiler/C library/whatever? By inheriting boost-utils and using the correct function to use older boost slot? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, 30 Oct 2012 16:02:59 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/10/12 04:00 PM, Alexis Ballier wrote: On Tue, 30 Oct 2012 15:56:21 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/10/12 03:45 PM, Tomáš Chvátal wrote: Dne Út 30. října 2012 20:24:26, Michał Górny napsal(a): On Tue, 30 Oct 2012 11:30:16 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? Simple, as any other lib, depend on older version and possibly port it forward. If that does not work then mask and wipe. Life goes on. If we un-slot boost there won't be an 'older' version available on users systems anymore; when the new boost hits ~arch and then stable, all ~arch / stable rdeps will -need- to build against that version of boost, period (or be lastrite'd as ssuominen suggested) unless i'm missing your meaning here? a sane pm wont try to upgrade to version 5 if 5 is required by some package. +1 for unslotting ..until something else ~arch (or stable) in the tree -needs- =5 (and we only need one fairly common package for that to happen), and then it all falls apart with same-slot conflicts. the good solution is obviously to keep it masked while proactively fixing packages and then unmask it. then there is absolutely no problem and that's what is generally done for other libraries.
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 12:31, Michael Mol wrote: I've never understood why Gentoo uses a separate ebuild for it. I mean, I can understand some efficiency gains from having a single compiled copy, but it shouldn't be surprising in the least when upstream makes breaking changes in the API. Because bundled libraries are bad. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 13:04, Ian Stakenvicius wrote: #1 - the MAX_BOOST_VERSION thing isn't needed anymore (and i get the impression that it actually is, but putting that aside since i don't maintain any packages that depend on boost), and It'll just behave like _every other library_ we have in the tree, as Samuli and Alexis already said. And it'll follow the same policy. #2 - anything requiring boost gets bumped to EAPI5 to get the slot-operator benefits for rebuilds, I'm not sure if it's strictly needed but it's fine. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 13:10, Michał Górny wrote: By inheriting boost-utils and using the correct function to use older boost slot? Which will not work. Can you build boost-1.49 with glibc-2.16? NO! At least not without patching it by changing its API. So how do you propose to solve package A that doesn't build with boost-1.50? Depend on 1.49? Which then depends on glibc-2.16? FFS, get a clue. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 13:39, Michael Mol wrote: In general, I agree...but Boost wasn't intended to be a shared library, so there shouldn't be a conflict there. But there are shared libraries, and they are not small either. And I'd rather, say, hunt an RWX section problem (a security problem) with a single shared library rather than having to hunt it down in a dozen or so. Besides, honestly it's not that bad. I think that half the headache that we're having is due to the slotting more than from boost itself. And the other half is due to people actually not going to fix their crap because oh I can just use the older version (until a new compiler or C library comes out). I've had to do my share of porting to newer boost — and as I said most of the headaches have been for the build system to find the object, rather than anything else. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, Oct 30, 2012 at 4:45 PM, Diego Elio Pettenò flamee...@flameeyes.euwrote: On 30/10/2012 13:39, Michael Mol wrote: In general, I agree...but Boost wasn't intended to be a shared library, so there shouldn't be a conflict there. But there are shared libraries, and they are not small either. And I'd rather, say, hunt an RWX section problem (a security problem) with a single shared library rather than having to hunt it down in a dozen or so. Besides, honestly it's not that bad. I think that half the headache that we're having is due to the slotting more than from boost itself. And the other half is due to people actually not going to fix their crap because oh I can just use the older version (until a new compiler or C library comes out). I've had to do my share of porting to newer boost — and as I said most of the headaches have been for the build system to find the object, rather than anything else. Thank you. That was enlightening. :) -- :wq
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/12 22:49, Michael Mol wrote: On Tue, Oct 30, 2012 at 4:45 PM, Diego Elio Pettenò flamee...@flameeyes.eu mailto:flamee...@flameeyes.eu wrote: On 30/10/2012 13:39, Michael Mol wrote: In general, I agree...but Boost wasn't intended to be a shared library, so there shouldn't be a conflict there. But there are shared libraries, and they are not small either. And I'd rather, say, hunt an RWX section problem (a security problem) with a single shared library rather than having to hunt it down in a dozen or so. Besides, honestly it's not that bad. I think that half the headache that we're having is due to the slotting more than from boost itself. And the other half is due to people actually not going to fix their crap because oh I can just use the older version (until a new compiler or C library comes out). I've had to do my share of porting to newer boost — and as I said most of the headaches have been for the build system to find the object, rather than anything else. Thank you. That was enlightening. :) Please remove HTML from your e-mail clients settings, at least for this mailing list. It's unreadable.
Re: [gentoo-dev] [RFC] Dropping slotted boost
On Tue, Oct 30, 2012 at 4:59 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 30/10/12 22:49, Michael Mol wrote: On Tue, Oct 30, 2012 at 4:45 PM, Diego Elio Pettenò flamee...@flameeyes.eu mailto:flamee...@flameeyes.eu wrote: On 30/10/2012 13:39, Michael Mol wrote: In general, I agree...but Boost wasn't intended to be a shared library, so there shouldn't be a conflict there. But there are shared libraries, and they are not small either. And I'd rather, say, hunt an RWX section problem (a security problem) with a single shared library rather than having to hunt it down in a dozen or so. Besides, honestly it's not that bad. I think that half the headache that we're having is due to the slotting more than from boost itself. And the other half is due to people actually not going to fix their crap because oh I can just use the older version (until a new compiler or C library comes out). I've had to do my share of porting to newer boost — and as I said most of the headaches have been for the build system to find the object, rather than anything else. Thank you. That was enlightening. :) Please remove HTML from your e-mail clients settings, at least for this mailing list. It's unreadable. Apologies; didn't even realize it was enabled. Incidentally can you forward a screenshot to me so I can see exactly how poorly it integrated with your normal settings? I don't expect I can get GMail to take a bug report, but if its HTML emails are setting things like fixed sizes, that's something that needs to be brought up. (I certainly wasn't copy/pasting or setting _anything_ manually. I avoid that as much as possible.) -- :wq
Re: [gentoo-dev] [RFC] Dropping slotted boost
DEP == Diego Elio Pettenò flamee...@flameeyes.eu writes: DEP Among other things, with each GCC/GLIBC update all but a handful of DEP slots are kept working; in this case I think most if not all 1.50 DEP are broken. One datapoint: Since protage failed to preserve icu-49 for me, upon which boost depends, I found that 1.48 and 1.49 build with gcc 4.7.2; but none of the earlier versions did. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 16:34, James Cloos wrote: Since protage failed to preserve icu-49 for me, upon which boost depends, I found that 1.48 and 1.49 build with gcc 4.7.2; but none of the earlier versions did. And only 1.50+ will work with glibc-2.16. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] Dropping slotted boost
2012-10-30 19:30:16 Diego Elio Pettenò napisał(a): Given the amount of headaches that Boost seems to give us all, now thanks to the recent changes even more because Gentoo's boost is different from all others and no upstream default check seem to work correctly with it, I'm questioning the usefulness of having it slotted. Among other things, with each GCC/GLIBC update all but a handful of slots are kept working; in this case I think most if not all 1.50 are broken. So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? I think that slotting is needed, but pkg_postinst() could create (without using `eselect boost`) symlinks like /usr/include/boost etc. It is possible that a package works with e.g. Boost 1.50, but not 1.51, so it could use boost-utils.eclass with BOOST_MAX_SLOT set to 1.50. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 19:50, Arfrever Frehtes Taifersar Arahesis wrote: I think that slotting is needed, but pkg_postinst() could create (without using `eselect boost`) symlinks like /usr/include/boost etc. It is possible that a package works with e.g. Boost 1.50, but not 1.51, so it could use boost-utils.eclass with BOOST_MAX_SLOT set to 1.50. That still does *not* solve a thing. It solves the _current_ issue with glibc-2.16, and we'll be back to square one with gcc 4.8, or glibc 2.17, or icu 51, or $whatever_else_the_fuck $n+1. Crazy slots for no reason just have to stop. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] Dropping slotted boost
Am Dienstag, den 30.10.2012, 11:30 -0700 schrieb Diego Elio Pettenò: Given the amount of headaches that Boost seems to give us all, now thanks to the recent changes even more because Gentoo's boost is different from all others and no upstream default check seem to work correctly with it, I'm questioning the usefulness of having it slotted. Among other things, with each GCC/GLIBC update all but a handful of slots are kept working; in this case I think most if not all 1.50 are broken. So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? I agree. It really doesn't make sense to keep unbuildable stuff in the tree. The point of slotting it in the first place was also to force a rebuild of reverse dependencies to have them use newer boost (since at that time when boost slotting was introduced we had some API breakages occurring between versions). Now with the sub-slots we can simply use this feature to tell the PM to rebuild the stuff. I'll also put cpp as herd for it in metadata.xml.
Re: [gentoo-dev] [RFC] Dropping slotted boost
On 30/10/2012 22:44, Tiziano Müller wrote: I agree. It really doesn't make sense to keep unbuildable stuff in the tree. The point of slotting it in the first place was also to force a rebuild of reverse dependencies to have them use newer boost (since at that time when boost slotting was introduced we had some API breakages occurring between versions). Now with the sub-slots we can simply use this feature to tell the PM to rebuild the stuff. Well, as long as the soname is correct (which it is), with preserved-rebuild (which is now available on ~arch Portage as well), this is basically already possible to some extent without even using subslots. Each new minor version bump (1.49 - 1.50) will orphan the 1.49 libraries, @preserved-rebuild will rebuild the linked packages. Of course for those that don't link to the objects, but only use the headers, the sub-slots make it possible as well. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
