[gentoo-dev] [RFC] Dropping slotted boost

[gentoo-dev] [RFC] Dropping slotted boost

[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?

Thanks,
-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

On Tue, 30 Oct 2012 11:30:16 -0700
Diego Elio Pettenò <flameeyes@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

On Tue, Oct 30, 2012 at 3:24 PM, Michał Górny <mgorny@gentoo.org> wrote:

> On Tue, 30 Oct 2012 11:30:16 -0700
> Diego Elio Pettenò <flameeyes@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

[-- Attachment #2: Type: text/html, Size: 1855 bytes --]

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Samuli Suominen]

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

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 551 bytes --]

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Tomáš Chvátal]

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ò <flameeyes@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

[Ian Stakenvicius]

-----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ò <flameeyes@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

[Alexis Ballier]

On Tue, 30 Oct 2012 15:56:21 -0400
Ian Stakenvicius <axs@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ò <flameeyes@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

[Ian Stakenvicius]

-----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
> <axs@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ò <flameeyes@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.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCQMnMACgkQ2ugaI38ACPAfSAD/d4PZXfXVhZRFaG+fVCa64vYn
r7MbrM6QH/pwadKWDpYBAIfyeLGjroVxVwwOpmozkL6GBxLPTIgAMfMu9Fbe/zYw
=f3Oe
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Samuli Suominen]

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
>> <axs@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ò <flameeyes@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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/10/12 02:30 PM, Diego Elio Pettenò 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.
> 
> 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,

As log as:

#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

#2 - anything requiring boost gets bumped to EAPI5 to get the
slot-operator benefits for rebuilds,

..seems to make sense to me also.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCQMtYACgkQ2ugaI38ACPANHgEAkEFD/m87xg3KY6pzazUSqmZT
MWxLJDgC1sy8GlYeEzUA/iIdCu0pPOC90FUMSXP2tjCgZeiGu/OmjM0iJa4rtPUi
=FgJE
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

On Tue, 30 Oct 2012 12:32:57 -0700
Diego Elio Pettenò <flameeyes@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Alexis Ballier]

On Tue, 30 Oct 2012 16:02:59 -0400
Ian Stakenvicius <axs@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
> > <axs@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ò <flameeyes@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

[Diego Elio Pettenò]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 551 bytes --]

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 551 bytes --]

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

On Tue, Oct 30, 2012 at 4:26 PM, Diego Elio Pettenò
<flameeyes@flameeyes.eu>wrote:

> 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.
>

In general, I agree...but Boost wasn't intended to be a shared library, so
there shouldn't be a conflict there.

Now, I understand that it's supremely convenient to be able to fix a bug in
one place, rather than grep and patch that bug in the source of all the
other packages...but then you come back to messes spawning from upstream
not treating that as a supported configuration.

Though since I'm not contributing labor (apart from the five minutes to
write this email), I probably don't really have the right perspective.

-- 
:wq

[-- Attachment #2: Type: text/html, Size: 1388 bytes --]

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Diego Elio Pettenò]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

On Tue, Oct 30, 2012 at 4:45 PM, Diego Elio Pettenò
<flameeyes@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. :)

-- 
:wq

[-- Attachment #2: Type: text/html, Size: 1409 bytes --]

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Samuli Suominen]

On 30/10/12 22:49, Michael Mol wrote:
> On Tue, Oct 30, 2012 at 4:45 PM, Diego Elio Pettenò
> <flameeyes@flameeyes.eu <mailto:flameeyes@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

[Michael Mol]

On Tue, Oct 30, 2012 at 4:59 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>
> On 30/10/12 22:49, Michael Mol wrote:
>>
>> On Tue, Oct 30, 2012 at 4:45 PM, Diego Elio Pettenò
>> <flameeyes@flameeyes.eu <mailto:flameeyes@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

[James Cloos]

>>>>> "DEP" == Diego Elio Pettenò <flameeyes@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 <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Diego Elio Pettenò]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

[gentoo-dev] Re: [RFC] Dropping slotted boost

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

On Tue, 30 Oct 2012 13:45:38 -0700
Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:

> 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).

Ding!  We have a winner.


-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [RFC] Dropping slotted boost

[Duncan]

Diego Elio Pettenò posted on Tue, 30 Oct 2012 16:41:40 -0700 as excerpted:

> 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.

???

icu-49.1.2 seems to build just fine against glibc-2.16.0, here.  I just 
rebuilt to be sure.  (With gcc-4.7.2.)

I have 50 masked due to the gptfdisk bug, but 49.1.2 continues to build, 
and AFAICT, work, here.  And I just double-checked, nothing in 
/etc/portage/patches or /etc/portage/env, and no overlay ebuild either, 
so I'm building straight from tree.

Of course being UTF8.en-US, I don't do anything exotic with unicode 
except the occasional web page or net radio or utube/minitube video, but 
I've not seen any crashing.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [RFC] Dropping slotted boost

[Diego Elio Pettenò]

On 30/10/2012 17:42, Duncan wrote:
> 
> icu-49.1.2 seems to build just fine against glibc-2.16.0, here.  I just 
> rebuilt to be sure.  (With gcc-4.7.2.)

I said "1.50+", I'm referring to Boost.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

[gentoo-dev] Re: [RFC] Dropping slotted boost

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

On Tue, 30 Oct 2012 19:34:02 -0400
James Cloos <cloos@jhcloos.com> wrote:

> >>>>> "DEP" == Diego Elio Pettenò <flameeyes@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.

And I had to argue to get 1.48 fixed.  I'm not sure why we have to keep so
many unbuildable versions in the tree.


-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [RFC] Dropping slotted boost

[Diego Elio Pettenò]

On 30/10/2012 17:49, Ryan Hill wrote:
> And I had to argue to get 1.48 fixed.  I'm not sure why we have to keep so
> many unbuildable versions in the tree.

Because as mgorny explained earlier he's expecting some fairy to make it
possible to _always_ install an older boost just because it's slotted.

Honestly, from what I can tell, Mike is doing, exactly like for ICU, a
direct proxying of commits from a developer that has been explicitly
kicked out by Gentoo, mgorny is in some fantasyland where the presence
of an ebuild makes it possible to build it just because it's slotted
(and his only commit is to add himself to metadata), Tiziano has been
last seen dropping eselect boost in favour of ... nothing, and Sebastian
Luther I have no word of in a long time.

I'm pretty sure that if the package was moved to cpp, or toolchain, or
whatever, is going to be better maintained by whatever is going on now
even if it's just going to be re-active instead of pro-active.

In the list of bugs for boost, most of the recently RESOLVED ones are
NOT related to boost itself, but to the reverse dependencies — lots of
them also seem to be due to >=boost-1.50-r2 which is without eselect boost.

Of the open ones, I'm pretty sure that a lot of them are obsolete such
as bug #334659 "dev-libs/boost is built as non-PIC on amd64", plus we
got a number of trackers, ICEs, stabilization bugs still open, and so on
so forth.

I have unfortunately a few packages using it; so does Tomáš — KDE and
MySQL depend on it as well. Is there somebody else interested in the
package? We might just want to take this over and restore some sanity.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 1026 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Diego Elio Pettenò]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

[gentoo-dev] Re: [RFC] Dropping slotted boost

[Diego Elio Pettenò]

Okay let's see a moment what's going on with the slotted boost.

www-plugins/gnash has a blocker on the old unslotted boost because it
doesn't really support multiple boost that well, like most other packages.

sci-biology/cufflinks and sci-biology/express are next to completely
screwed because they are hardcoding boost-1.46 (which is soon going to
make them unusable). Besides, cufflinks shows that it's the kind of crap
that should never have entered the tree, considering that filter-ldflags
on --as-needed which is not going to do its job even if you pray.

dev-util/intel-ocl-sdk does the same, but it might just install its own
version since it's not going to work anyway.

There was an ebuild for net-analyzer/sslsniff but I removed it since
there was a -r1 that works just fine with 1.47 and later.

I'm going to give it time till tomorrow to hear if somebody has a good
reason to have the slotting (which has to be a _valid_ reason, not a
fantasy reason like the ones I heard today about being able to install
1.35 on a modern system).

If nobody else can demonstrate a need and a way to leverage the
slotting, I'll go with just go this way:

 - maintainership moved to me+scarabeus+cpp herd (which means Tiziano is
still there, btw);
 - blocker on gnash removed;
 - intel-ocl-sdk, cufflinks and express will request a particular
version (which makes them trouble, but it's mesesd up all the same —
optionally I could just go and mask them until properly fixed);
 - old ebuilds removed from tree with their files, to reduce the rsync
trouble.

Hopefully then it'll work just as before, with the latest version
available unversioned so that old packages relying on eselect will work
out of the box, which is what should happen anyway.

I'll also run a tinderbox against 1.51, and will start to look into what
has to be done to fix whatever is still incompatible with it to work, so
that when glibc 2.16 gets out we can unmask this without breaking the
70% of the tree like an unmask of >=1.50-r2 would cause right now.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Tiziano Müller]

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

[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.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Tiziano Müller]

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 <herd>cpp</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] Re: [RFC] Dropping slotted boost

[Duncan]

Diego Elio Pettenò posted on Tue, 30 Oct 2012 17:45:27 -0700 as excerpted:

> On 30/10/2012 17:42, Duncan wrote:
>> 
>> icu-49.1.2 seems to build just fine against glibc-2.16.0, here.  I just
>> rebuilt to be sure.  (With gcc-4.7.2.)
> 
> I said "1.50+", I'm referring to Boost.

Thanks.  Makes MUCH more sense when I have the right package (and 
version) in mind! =;^)

(I had mixed them up before, but caught myself until now.  This time I 
didn't.  Thanks again.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [RFC] Dropping slotted boost

[Samuli Suominen]

On 31/10/12 03:03, Diego Elio Pettenò wrote:
> On 30/10/2012 17:49, Ryan Hill wrote:
>> And I had to argue to get 1.48 fixed.  I'm not sure why we have to keep so
>> many unbuildable versions in the tree.
>
> Because as mgorny explained earlier he's expecting some fairy to make it
> possible to _always_ install an older boost just because it's slotted.
>
> Honestly, from what I can tell, Mike is doing, exactly like for ICU, a
> direct proxying of commits from a developer that has been explicitly
> kicked out by Gentoo, mgorny is in some fantasyland where the presence
> of an ebuild makes it possible to build it just because it's slotted
> (and his only commit is to add himself to metadata), Tiziano has been
> last seen dropping eselect boost in favour of ... nothing, and Sebastian
> Luther I have no word of in a long time.
>
> I'm pretty sure that if the package was moved to cpp, or toolchain, or
> whatever, is going to be better maintained by whatever is going on now
> even if it's just going to be re-active instead of pro-active.
>
> In the list of bugs for boost, most of the recently RESOLVED ones are
> NOT related to boost itself, but to the reverse dependencies — lots of
> them also seem to be due to >=boost-1.50-r2 which is without eselect boost.
>
> Of the open ones, I'm pretty sure that a lot of them are obsolete such
> as bug #334659 "dev-libs/boost is built as non-PIC on amd64", plus we
> got a number of trackers, ICEs, stabilization bugs still open, and so on
> so forth.
>
> I have unfortunately a few packages using it; so does Tomáš — KDE and
> MySQL depend on it as well. Is there somebody else interested in the
> package? We might just want to take this over and restore some sanity.
>

[picked near random mail from this thread, as this seemed most suitable]

We have been in this situation before where I've had to clean out old 
boost versions because the toolchain went forward as it should.

   22 Apr 2010; Samuli Suominen <ssuominen@gentoo.org>
   -boost-1.36.0-r1.ebuild:
   Remove boost-1.36.0 for gcc-porting wrt #287638.

So all of this should come as no suprise to anyone.

- Samuli