| 1 |
Alex Alexander wrote: |
| 2 |
> QT doesn't work well when mixed versions of its core libraries are |
| 3 |
> installed. Usually an emerge -avDu world solves the problem, but some |
| 4 |
> users tend to avoid this. |
| 5 |
> |
| 6 |
> For example, lets say you have parts of QT 4.4.2 on your system. QT |
| 7 |
> 4.5.1 is available and a user decides to manually update qt-core, or |
| 8 |
> to install KDE which has a QT dependency on a QT library not |
| 9 |
> installed. In these cases, portage will update only a part of the |
| 10 |
> installed QT libraries, leaving the system in a mixed state. |
| 11 |
> |
| 12 |
> QT based apps don't like that. Others will refuse to build, others |
| 13 |
> will fail to run. |
| 14 |
> |
| 15 |
> We've managed to experimentally block partial QT upgrades by adding an |
| 16 |
> RDEPEND to all QT libraries [1] in qting-edge overlay. Portage |
| 17 |
> understands this and throws out B blocks if you try to change versions |
| 18 |
> only in parts of QT, but upgrades/downgrades fine if you do them all |
| 19 |
> at once (or use -Du world). |
| 20 |
> |
| 21 |
> This "fix" also catches stale QT libraries that nothing depends on |
| 22 |
> anymore because the user has removed whatever required them (and never |
| 23 |
> ran --depclean). |
| 24 |
> |
| 25 |
> Unfortunately we've got reports from paludis users stating that they |
| 26 |
> can't update QT from qting-edge anymore. |
| 27 |
|
| 28 |
From what I understand you are utilizing portages ability to |
| 29 |
automagically resolve blockers when all blockers will be resolved within |
| 30 |
the current command. Agree?? or is it the fact that you are doing |
| 31 |
!>x11-libs/qt-assistant-${PV}-r9999 that is causing the paludis problem? |
| 32 |
|
| 33 |
I would suggest that you just tell paludis users to use --dl-blocks |
| 34 |
discard when updating qt. After looking at the eclass im not sure |
| 35 |
whether it will work or not. im assuming that discarding blocks will |
| 36 |
just ignore everything, but I haven't tested it so can't be sure. |
| 37 |
|
| 38 |
> |
| 39 |
> What I'd like to discuss is the following: |
| 40 |
> |
| 41 |
> 1) Is there a saner way to achieve our goal of doing whatever is |
| 42 |
> possible to avoid mixed QT versions? |
| 43 |
|
| 44 |
I don't believe so, not within current ways of declaring dependencies. |
| 45 |
|
| 46 |
> 2) Is our implementation considered correct and acceptable by the PMS guys? |
| 47 |
> 3) Whats the general Gentoo Policy on mixed versions? Do we care, or |
| 48 |
> is our policy "please -Du world"? |
| 49 |
|
| 50 |
I say we should be stopping them from happening. |
| 51 |
|
| 52 |
> |
| 53 |
> We've also managed to achieve the same thing by adding PDEPENDs to |
| 54 |
> each QT library for any other QT libraries that depend on it: |
| 55 |
> |
| 56 |
> i.e. if qt-xmlpatterns depends on qt-gui, we add the following to qt-gui: |
| 57 |
> PDEPEND=" |
| 58 |
> || ( !x11-libs/qt-xmlpatterns ~x11-libs/qt-xmlpatterns-${PV} ) |
| 59 |
> " |
| 60 |
> |
| 61 |
> the above (expanded for all libraries) has the same effect as the [1] |
| 62 |
> RDEPEND but looks a bit more hackish. |
| 63 |
> |
| 64 |
|
| 65 |
And I would agree with the hackish comment. |
| 66 |
|
| 67 |
> thanks |
| 68 |
|
| 69 |
Good work btw. |
| 70 |
|
| 71 |
Alistair. |
Archives