| 1 |
Am Tue, 26 Sep 2017 11:45:45 -0700 |
| 2 |
schrieb Ian Zimmerman <itz@××××××××××××.org>: |
| 3 |
|
| 4 |
> On 2017-09-26 22:01, Michael Palimaka wrote: |
| 5 |
> |
| 6 |
> > If the only argument is you don't want to upgrade, I'm afraid |
| 7 |
> > there's not much we can do to help you. |
| 8 |
> |
| 9 |
> You're right that I don't want to upgrade, and I have already |
| 10 |
> explained my workaround for that. But that is _not_ what I'm |
| 11 |
> complaining about in this thread. Rather, my complaint is that such |
| 12 |
> a major change is hidden in an ebuild edit with no version/revision |
| 13 |
> bump, which means I cannot use the normal means (ie. package.mask) to |
| 14 |
> prevent it. Before I decided to drop Qt completely, I had to make a |
| 15 |
> local package of qtcustomplot in my own repo. |
| 16 |
|
| 17 |
If you don't want (or cannot) upgrade, you have two options: |
| 18 |
|
| 19 |
1. Prepare to maintain your own overlay and deal with it |
| 20 |
|
| 21 |
2. Don't use a rolling release distribution |
| 22 |
|
| 23 |
|
| 24 |
Personally, and since you seem to know enough to manage your own |
| 25 |
overlay, I'd stick to #1. |
| 26 |
|
| 27 |
|
| 28 |
> Surely there are other reasons against this kind of thing? What if |
| 29 |
> someone reports a bug in the package? Now you don't know from the |
| 30 |
> version/rev number if it's linked with Qt4 or Qt5. Is that not |
| 31 |
> important? |
| 32 |
|
| 33 |
The problem seems to be that while the package can be built against |
| 34 |
both qt4 and qt5, qt4 wasn't present at all. |
| 35 |
|
| 36 |
A proper way I'm sure you could have arranged with, would have been to |
| 37 |
introduce both useflags, then mask the qt4 useflag and mark it for |
| 38 |
removal during the next version bump. That would have given you an easy |
| 39 |
opportunity to properly react to the change, by either unmasking the |
| 40 |
flag and pinning the version, or copy the ebuild from db/pkg to your |
| 41 |
own overlay. |
| 42 |
|
| 43 |
I don't know how Gentoo policy suggests but I'm pretty sure this is one |
| 44 |
of the official ways to prevent exactly your problem. |
| 45 |
|
| 46 |
In the long way, tho, due to qt4 breakage, the qt5 useflag had to be |
| 47 |
introduced, and qt4 support had to be dropped. But maybe not in just |
| 48 |
one single step without revbump. |
| 49 |
|
| 50 |
The change causes rebuilds for most qt users anyways, as either you had |
| 51 |
one of the flags enabled and that resulted in a useflag change thus |
| 52 |
rebuild, or: None of the useflags was set, and then you were not |
| 53 |
affected (which probably was the "short sighted" decision for doing it |
| 54 |
without a revbump in the first place). |
| 55 |
|
| 56 |
|
| 57 |
-- |
| 58 |
Regards, |
| 59 |
Kai |
| 60 |
|
| 61 |
Replies to list-only preferred. |
Archives