1 |
Jan Matejka wrote: |
2 |
|
3 |
> -----BEGIN PGP SIGNED MESSAGE----- |
4 |
> Hash: SHA512 |
5 |
> |
6 |
> On Tue, 24 Jun 2014 21:25:40 +0200 |
7 |
> Jörg Schaible <joerg.schaible@×××.de> wrote: |
8 |
> |
9 |
>> Alexandre Rostovtsev wrote: |
10 |
>> |
11 |
>> > On Mon, 2014-06-23 at 22:15 +0200, Jörg Schaible wrote: |
12 |
>> >> So, why the heck, was the dependency to dev-libs/glib changed for |
13 |
>> >> an existing ebuild without increasing its version (e.g. |
14 |
>> >> dbus-glib-0.100.2-r2)? |
15 |
>> > |
16 |
>> > Please see http://article.gmane.org/gmane.linux.gentoo.devel/91615 |
17 |
>> |
18 |
>> These blocks had nothing to do with the multilibs ABI. It has been |
19 |
>> just the updated versions for the dependencies. |
20 |
>> |
21 |
>> >> I have to use an older Eclipse 3.8.x version for my daily work and |
22 |
>> >> since it is broken with latest gtk versions (a lot of crashes), I |
23 |
>> >> use still some old ebuilds and have masked new ones. |
24 |
>> > |
25 |
>> > Please file a bug report about this. If nobody tells us that a new |
26 |
>> > gtk+ version broke something important, we will soon mark the new |
27 |
>> > version as stable and then remove the old version. |
28 |
> |
29 |
> My understanding the problematic change is: |
30 |
> |
31 |
> - -CDEPEND=">=dev-libs/expat-2[${MULTILIB_USEDEP}] |
32 |
> - - >=dev-libs/glib-2.26:2[${MULTILIB_USEDEP}] |
33 |
> - - >=sys-apps/dbus-1.6.2[${MULTILIB_USEDEP}]" |
34 |
> +CDEPEND=">=dev-libs/expat-2.1.0-r3[${MULTILIB_USEDEP}] |
35 |
> + >=dev-libs/glib-2.38.2-r1:2[${MULTILIB_USEDEP}] |
36 |
> + >=sys-apps/dbus-1.6.18-r1[${MULTILIB_USEDEP}]" |
37 |
> |
38 |
> given that only micro version was bumped for dbus and while glib |
39 |
> changes minor version, it's the same slot. Therefore my understanding |
40 |
> is the resulting libraries should not break API/ABI and therefore there |
41 |
> shouldn't be an issue. |
42 |
|
43 |
|
44 |
Except if they're locally hard masked ... ;-) |
45 |
|
46 |
|
47 |
> In that case I think revbump is not warranted since it should continue |
48 |
> to work for existing installation and new installations shouldn't be |
49 |
> any different beside the dependency and not revbumping eliminates some |
50 |
> needless rebuilts. |
51 |
|
52 |
|
53 |
The point is: Why update silently the dependency versions for a stable |
54 |
release? Especially in this case, because the now "required" versions are |
55 |
the oldest stable ones in the official tree. Therefore anyone with the |
56 |
official tree would have had those anyway. But such an action may affect |
57 |
anyone with a local tree or overlays. |
58 |
|
59 |
|
60 |
> And that seems to be the case since you say it's actually problem in |
61 |
> eclipse … |
62 |
> |
63 |
>> I report anything, if it is worth it. However, in this case the |
64 |
>> problem is on Eclipse's side and fixed in newer versions. Alas, it |
65 |
>> does not help me, because I have to use that old version for my daily |
66 |
>> work. So, there's no blame on Gentoo and nothing the devs should have |
67 |
>> to waste their time. |
68 |
>> |
69 |
>> Therefore I still use the once stable versions of GTK (~5 months old |
70 |
>> now), where this old version of Eclipse runs, i.e. I already |
71 |
>> preserved some older versions locally that are already vanished from |
72 |
>> the portage tree. The newer ones are hard masked. |
73 |
>> |
74 |
>> However, if some of my currently installed stable packages suddenly |
75 |
>> require newer versions, my portage tree gets in serious trouble. |
76 |
>> Nothing would have happen if the revision number of the affected |
77 |
>> packages had been simply increased. |
78 |
> |
79 |
> I guess you could fork the needed packages (you can always get older |
80 |
> versions from cvs) into your custom overlay for old eclipse and maintain |
81 |
> them there under some slot. |
82 |
|
83 |
|
84 |
That's what I actually did for all "bumped" packages in the end. Effort for |
85 |
nothing. |
86 |
|
87 |
|
88 |
> Caveat Emptor: I'm not particulary experienced with neither API/ABI |
89 |
> changes and slotting so I don't know how accurate this information is. |
90 |
|
91 |
|
92 |
Cheers, |
93 |
Jörg |