Gentoo Archives: gentoo-dev

From: Alexis Ballier <aballier@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] Dropping slotted boost
Date: Tue, 30 Oct 2012 20:16:32
Message-Id: 20121030171403.077b14fe@gentoo.org
In Reply to: Re: [gentoo-dev] [RFC] Dropping slotted boost by Ian Stakenvicius
1 On Tue, 30 Oct 2012 16:02:59 -0400
2 Ian Stakenvicius <axs@g.o> wrote:
3
4 > -----BEGIN PGP SIGNED MESSAGE-----
5 > Hash: SHA256
6 >
7 > On 30/10/12 04:00 PM, Alexis Ballier wrote:
8 > > On Tue, 30 Oct 2012 15:56:21 -0400 Ian Stakenvicius
9 > > <axs@g.o> wrote:
10 > >
11 > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
12 > >>
13 > >> On 30/10/12 03:45 PM, Tomáš Chvátal wrote:
14 > >>> Dne Út 30. října 2012 20:24:26, Michał Górny napsal(a):
15 > >>>> On Tue, 30 Oct 2012 11:30:16 -0700
16 > >>>>
17 > >>>> Diego Elio Pettenò <flameeyes@×××××××××.eu> wrote:
18 > >>
19 > >>>>
20 > >>>>> So given that it's a PITA for the maintainers, a PITA for
21 > >>>>> the users, eselect boost has been shown to be a bad idea
22 > >>>>> and so on ... can we just go back to just install it and
23 > >>>>> that's about it?
24 > >>>>
25 > >>>> How are you going to solve the issue of a lot of packages
26 > >>>> being broken with new boost versions? Are you volunteering to
27 > >>>> keep fixing them with each release?
28 > >>>
29 > >>> Simple, as any other lib, depend on older version and possibly
30 > >>> port it forward. If that does not work then mask and wipe. Life
31 > >>> goes on.
32 > >>>
33 > >>
34 > >> If we un-slot boost there won't be an 'older' version available
35 > >> on users systems anymore; when the new boost hits ~arch and then
36 > >> stable, all ~arch / stable rdeps will -need- to build against
37 > >> that version of boost, period (or be lastrite'd as ssuominen
38 > >> suggested) .... unless i'm missing your meaning here?
39 > >
40 > > a sane pm wont try to upgrade to version 5 if <5 is required by
41 > > some package.
42 > >
43 > > +1 for unslotting
44 > >
45 >
46 > ..until something else ~arch (or stable) in the tree -needs- >=5 (and
47 > we only need one fairly common package for that to happen), and then
48 > it all falls apart with same-slot conflicts.
49 >
50
51 the good solution is obviously to keep it masked while proactively
52 fixing packages and then unmask it. then there is absolutely no problem
53 and that's what is generally done for other libraries.