1 |
On Fri, Jul 27, 2012 at 11:27 PM, Ben de Groot <yngwin@g.o> wrote: |
2 |
> On 28 July 2012 13:59, Nikos Chantziaras <realnc@×××××.com> wrote: |
3 |
>> On 28/07/12 08:22, Ben de Groot wrote: |
4 |
>>> |
5 |
>>> In preparation for that, we want to ask maintainers of all ebuilds in |
6 |
>>> the tree with dependencies on Qt4, to make sure that they have the |
7 |
>>> proper slot. Otherwise your package may pull in Qt5 while it may not |
8 |
>>> in fact support it. |
9 |
>> |
10 |
>> |
11 |
>> This can be trouble if the application actually works with Qt5. It might |
12 |
>> depend on Qt4 but has no problems with Qt5 (contrary to Qt3 vs Qt4, Qt5 is |
13 |
>> mostly compatible with much of existing Qt4 code), needlessly pulling-in |
14 |
>> Qt4. Many applications simply build and run as-is and no code changes are |
15 |
>> necessary. |
16 |
>> |
17 |
>> So what would be the methodology of making sure a package has the proper |
18 |
>> slot? |
19 |
> |
20 |
> Obviously you would need to make sure that the package actually does |
21 |
> support Qt5. Then, as I see it, we could do either: |
22 |
> |
23 |
> || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 ) |
24 |
> |
25 |
|
26 |
This is wrong because qt4 and qt5 are not binary compatible. |
27 |
|
28 |
> or: |
29 |
> |
30 |
> qt4? ( x11-libs/qt-gui:4 ) |
31 |
> qt5? ( x11-libs/qt-gui:5 ) |
32 |
> |
33 |
|
34 |
This is the only alternative AFAICS. |
35 |
|
36 |
Thanks, |
37 |
Pesa |