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
