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