public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Jan Matejka <yac@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: Changes in installed ebuilds
Date: Wed, 25 Jun 2014 12:24:27 +0200	[thread overview]
Message-ID: <20140625122427.7d8f0865@deathstar> (raw)
In-Reply-To: <locjbl$gii$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Tue, 24 Jun 2014 21:25:40 +0200
Jörg Schaible <joerg.schaible@gmx.de> 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.

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.

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.

Caveat Emptor: I'm not particulary experienced with neither API/ABI
changes and slotting so I don't know how accurate this information is.


- --
Jan Matějka        | Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCgAGBQJTqqNfAAoJEIN+7RD5ejah2J4H/0QOC7K1CYzF91HNbP6T3S/v
pl2vRF9JvOg5+SS/GzO7gqu8YPIF/GaViXPTWps7Ab6SqT0ARf3IPA0v6NCXymqf
vSUKMZDOVtBGq5mUjhiBTFZYFLtp0Nnj0lgv8ysv40ObzKvaT/Af7xGz67zm83pl
v0nr0gArH4oVVXFZg9w/22cw+0jLEaagLwS2SbgHsVgOfPBWHrIEMM46lk+DyEq6
wq1RMgMrFQ+QXHdO4zKM0+xLGahL3So05j7xlKmg4jIKlnlxXalYn3WY/ebrSoR3
uSuerahzlDo+qKR31Rldc/piurah7KnNoJSFa+Yny7upcueb0aWHbcPcZ9Js35o=
=ULrp
-----END PGP SIGNATURE-----

  parent reply	other threads:[~2014-06-25 10:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-23 20:15 [gentoo-dev] Changes in installed ebuilds Jörg Schaible
2014-06-23 23:14 ` [gentoo-dev] " Duncan
2014-06-24  0:49 ` [gentoo-dev] " Alexandre Rostovtsev
2014-06-24 19:25   ` [gentoo-dev] " Jörg Schaible
2014-06-24 20:47     ` Kristian Fiskerstrand
2014-06-24 21:15       ` hasufell
2014-06-25 22:48         ` [gentoo-dev] " Jörg Schaible
2014-06-26  7:13           ` Michał Górny
2014-06-26 22:04             ` [gentoo-dev] " Jörg Schaible
2014-06-24 21:27     ` [gentoo-dev] " hasufell
2014-06-25 22:46       ` [gentoo-dev] " Jörg Schaible
2014-06-25 10:24     ` Jan Matejka [this message]
2014-06-25 22:42       ` Jörg Schaible
2014-06-25 23:31         ` Alex Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140625122427.7d8f0865@deathstar \
    --to=yac@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox