From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A206213877A for ; Wed, 25 Jun 2014 22:43:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B5C42E0AC8; Wed, 25 Jun 2014 22:42:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CC6C8E0A80 for ; Wed, 25 Jun 2014 22:42:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id EC7AD340030 for ; Wed, 25 Jun 2014 22:42:43 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -0.255 X-Spam-Level: X-Spam-Status: No, score=-0.255 tagged_above=-999 required=5.5 tests=[AWL=-0.244, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IypPl3Ir45F for ; Wed, 25 Jun 2014 22:42:37 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 81A47340033 for ; Wed, 25 Jun 2014 22:42:36 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Wzvtg-0006KK-IH for gentoo-dev@gentoo.org; Thu, 26 Jun 2014 00:42:32 +0200 Received: from hsi-kbw-109-192-107-076.hsi6.kabel-badenwuerttemberg.de ([109.192.107.76]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Jun 2014 00:42:32 +0200 Received: from joerg.schaible by hsi-kbw-109-192-107-076.hsi6.kabel-badenwuerttemberg.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Jun 2014 00:42:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: =?UTF-8?B?SsO2cmc=?= Schaible Subject: [gentoo-dev] Re: Re: Changes in installed ebuilds Date: Thu, 26 Jun 2014 00:42:22 +0200 Message-ID: References: <1403570947.24976.1.camel@rook> <20140625122427.7d8f0865@deathstar> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: hsi-kbw-109-192-107-076.hsi6.kabel-badenwuerttemberg.de User-Agent: KNode/4.12.5 X-Archives-Salt: 1252434a-00f6-4999-b184-d3e13293d225 X-Archives-Hash: b774921e9b8a01c80d9fbf49f6f8449f Jan Matejka wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On Tue, 24 Jun 2014 21:25:40 +0200 > Jörg Schaible wrote: > >> Alexandre Rostovtsev wrote: >> >> > On Mon, 2014-06-23 at 22:15 +0200, Jörg Schaible wrote: >> >> So, why the heck, was the dependency to dev-libs/glib changed for >> >> an existing ebuild without increasing its version (e.g. >> >> dbus-glib-0.100.2-r2)? >> > >> > Please see http://article.gmane.org/gmane.linux.gentoo.devel/91615 >> >> These blocks had nothing to do with the multilibs ABI. It has been >> just the updated versions for the dependencies. >> >> >> I have to use an older Eclipse 3.8.x version for my daily work and >> >> since it is broken with latest gtk versions (a lot of crashes), I >> >> use still some old ebuilds and have masked new ones. >> > >> > Please file a bug report about this. If nobody tells us that a new >> > gtk+ version broke something important, we will soon mark the new >> > version as stable and then remove the old version. > > My understanding the problematic change is: > > - -CDEPEND=">=dev-libs/expat-2[${MULTILIB_USEDEP}] > - - >=dev-libs/glib-2.26:2[${MULTILIB_USEDEP}] > - - >=sys-apps/dbus-1.6.2[${MULTILIB_USEDEP}]" > +CDEPEND=">=dev-libs/expat-2.1.0-r3[${MULTILIB_USEDEP}] > + >=dev-libs/glib-2.38.2-r1:2[${MULTILIB_USEDEP}] > + >=sys-apps/dbus-1.6.18-r1[${MULTILIB_USEDEP}]" > > given that only micro version was bumped for dbus and while glib > changes minor version, it's the same slot. Therefore my understanding > is the resulting libraries should not break API/ABI and therefore there > shouldn't be an issue. Except if they're locally hard masked ... ;-) > In that case I think revbump is not warranted since it should continue > to work for existing installation and new installations shouldn't be > any different beside the dependency and not revbumping eliminates some > needless rebuilts. The point is: Why update silently the dependency versions for a stable release? Especially in this case, because the now "required" versions are the oldest stable ones in the official tree. Therefore anyone with the official tree would have had those anyway. But such an action may affect anyone with a local tree or overlays. > And that seems to be the case since you say it's actually problem in > eclipse … > >> I report anything, if it is worth it. However, in this case the >> problem is on Eclipse's side and fixed in newer versions. Alas, it >> does not help me, because I have to use that old version for my daily >> work. So, there's no blame on Gentoo and nothing the devs should have >> to waste their time. >> >> Therefore I still use the once stable versions of GTK (~5 months old >> now), where this old version of Eclipse runs, i.e. I already >> preserved some older versions locally that are already vanished from >> the portage tree. The newer ones are hard masked. >> >> However, if some of my currently installed stable packages suddenly >> require newer versions, my portage tree gets in serious trouble. >> Nothing would have happen if the revision number of the affected >> packages had been simply increased. > > I guess you could fork the needed packages (you can always get older > versions from cvs) into your custom overlay for old eclipse and maintain > them there under some slot. That's what I actually did for all "bumped" packages in the end. Effort for nothing. > Caveat Emptor: I'm not particulary experienced with neither API/ABI > changes and slotting so I don't know how accurate this information is. Cheers, Jörg