[gentoo-dev] Changes in installed ebuilds

[gentoo-dev] Changes in installed ebuilds

[Jörg Schaible]

Hi,

can somebody tell my, since when existing (and installed) ebuilds suddenly 
change without at least increasing the version number?

Today's synchronization got me suddenly dependency conflicts for installed 
packages:

==================== %< =========================
!!! All ebuilds that could satisfy ">=dev-libs/glib-2.38.2-
r1:2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]" 
have been masked.
!!! One of the following masked packages is required to complete your 
request:
- dev-libs/glib-2.40.0-r1::gentoo (masked by: ~amd64 keyword)
- dev-libs/glib-2.38.2-r1::gentoo (masked by: package.mask)

(dependency required by "dev-libs/dbus-glib-0.100.2-r1" [installed])
(dependency required by "sys-auth/consolekit-0.4.6" [installed])
(dependency required by "sys-auth/polkit-0.112-r1[-systemd]" [installed])
(dependency required by "sys-fs/udisks-2.1.2" [installed])
(dependency required by "kde-base/kdelibs-4.12.5-r1[udisks]" [ebuild])
(dependency required by "kde-base/nepomuk-widgets-4.12.5" [installed])
==================== %< =========================

Diffing the ebuilds for dbus-glib:

==================== %< =========================
~ $ locate dbus-glib-0.100.2-r1.ebuild
/var/db/pkg/dev-libs/dbus-glib-0.100.2-r1/dbus-glib-0.100.2-r1.ebuild
/var/db/portage/central/dev-libs/dbus-glib/dbus-glib-0.100.2-r1.ebuild
~ $ diff -u `locate dbus-glib-0.100.2-r1.ebuild`
--- /var/db/pkg/dev-libs/dbus-glib-0.100.2-r1/dbus-glib-0.100.2-r1.ebuild       
2014-02-24 09:01:29.779074662 +0100
+++ /var/db/portage/central/dev-libs/dbus-glib/dbus-glib-0.100.2-r1.ebuild      
2014-06-18 21:31:11.000000000 +0200
@@ -1,6 +1,6 @@
 # Copyright 1999-2014 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/dev-libs/dbus-glib/dbus-glib-0.100.2-
r1.ebuild,v 1.7 2014/02/23 16:17:58 pacho Exp $
+# $Header: /var/cvsroot/gentoo-x86/dev-libs/dbus-glib/dbus-glib-0.100.2-
r1.ebuild,v 1.11 2014/06/18 19:09:23 mgorny Exp $
 
 EAPI=5
 inherit bash-completion-r1 eutils multilib-minimal
@@ -11,18 +11,18 @@
 
 LICENSE="|| ( GPL-2 AFL-2.1 )"
 SLOT="0"
-KEYWORDS="~alpha amd64 arm hppa ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc x86 
~amd64-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~arm-linux ~x86-linux ~ppc-
macos ~x86-macos ~m68k-mint ~sparc-solaris ~x86-solaris"
+KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 ~s390 ~sh sparc x86 
~amd64-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~arm-linux ~x86-linux ~ppc-
macos ~x86-macos ~m68k-mint ~sparc-solaris ~x86-solaris"
 IUSE="debug doc static-libs test"
 
-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}]"
 DEPEND="${CDEPEND}
        virtual/pkgconfig
        doc? ( >=dev-util/gtk-doc-1.4 )"
 RDEPEND="${CDEPEND}
-        abi_x86_32? (
-               !<app-emulation/emul-linux-x86-baselibs-20131008-r8
+       abi_x86_32? (
+               !<app-emulation/emul-linux-x86-baselibs-20131008-r8
                !app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)]
        )"
 
@@ -49,7 +49,7 @@
                $(use_enable debug verbose-mode)
                $(use_enable debug asserts)
                $(use_enable static-libs static)
-               $(multilib_build_binaries && use_enable doc gtk-doc || echo 
" --disable-gtk-doc")
+               $(multilib_native_use_enable doc gtk-doc)
        )
 
        ECONF_SOURCE="${S}" econf "${myconf[@]}"
==================== %< =========================

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)? 
Who can really say, that dbus-glib still works properly without having been 
compiled against those new versions of expat, glib and dbus? Sorry, but this 
is simply bad practice.

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. However, if the dependencies of installed 
ebuilds suddenly change, this simply breaks my portage tree.

- Jörg

[gentoo-dev] Re: Changes in installed ebuilds

[Duncan]

Jörg Schaible posted on Mon, 23 Jun 2014 22:15:39 +0200 as excerpted:

> can somebody tell my, since when existing (and installed) ebuilds
> suddenly change without at least increasing the version number?


That has always been the case.  Existing ebuilds aren't always bumped for 
changes, only if the changes are seen to be installation significant.  In 
particular, dependencies generated in eclasses can change, thus changing 
dependencies for the potentially many installed packages inheriting those 
eclasses. It's thus possible to correct minor problems without forcing a 
reinstall.

Tho that also means it's possible to screw things up, and occasionally 
that does happen.  I personally run --update --deep with all my updates 
here, and run ~arch (with gentoo/kde overlay live-kde) as well, and 
believe that spares me some big forced-upgrade jumps since I tend to be 
well ahead of the minimum version numbers and older, less current testing 
ebuilds, but I do think it makes a difference.  Additionally, mostly 
stable systems with a few ~arch keyworded packages is a known low-testing 
and not always anticipated corner-case.  All-stable and all-~arch systems 
are better tested and supported.

Without knowing/checking specifics and assuming it wasn't a stable/~arch 
mixed-system issue, the problem here was likely a screwup.  Someone 
didn't anticipate the effect of their update on your specific case, 
triggering an unintended result.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Changes in installed ebuilds

[Alexandre Rostovtsev]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

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

> 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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-dev] Re: Changes in installed ebuilds

[Jörg Schaible]

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.

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.

Cheers,
Jörg

Re: [gentoo-dev] Re: Changes in installed ebuilds

[Kristian Fiskerstrand]

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

On 06/24/2014 09:25 PM, 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.
> 

For what it is worth, I completely agree significant changes to stable
ebuilds (hereunder changes to dependencies) should get a revision bump
and go through normal stabilization procedures.

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Cogito ergo sum
I think, therefore I am
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTqePmAAoJEPw7F94F4TagI0cP/imaneK0trmqBHZn7xlKSmmR
/UA76zhcC6sAGcsJRGnLV3zd0WBpyrocVwrkPt8lVl1ZLBwy8K7d2VN1h9r40Prk
vMyIoIJbFHMQu2Jdl1EICRYjqHKgH0Jc4k9BiASTd149lG7TMFuGQQoS/ffXwyMR
N40XCPgWd0n7CSajQpUqL3ZzZ87UgLR5oykEC0wMkPzj8TZCoZoQu5FNadVHL7Ns
/ssd0j1gwq8WPsjSIPyd83Bq1Gmpgd5xYnH9QS0DNGTyisRs9gcAOBm5UFMZDJxh
kgz1sZTKRcQVsCY+SeTMDJFl1Q4BsE+hKyeNvSc76v5cNNKp+h+MtxKnVTv9HEVB
53qY1FXxQzk6m5KheqKFvtx1m1mCtB+TKrBzwMa4qZ7v++W7DxPxdFjf61t7t5EI
/+yDxnfdN5HGE0MZXHUtnI0frCGaDBi8+eGS83VRG7lUoYfiKcrQpJrLKxvO6o7y
esEuPXXFRQ6vAU9yav6JX0VXyhXzWi3A8qP845UYsSUQa61U0nEalBazzr+GmTv+
qhxYerSSMkK6QBtvOQDaC/vX9K6zstxDIiEkbkbCVlE/Ru5ux93jx3n3hG6m5deS
ev7L8Ws0xFbivltEeJFsqgfGehVB7BymjPbTCNaSy6d3zqYwvfjpcZANANlBErsA
9Y11wDWFvQcKU+ETt2lF
=92R7
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Changes in installed ebuilds

[hasufell]

Kristian Fiskerstrand:
> On 06/24/2014 09:25 PM, 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.
> 
> 
> For what it is worth, I completely agree significant changes to stable
> ebuilds (hereunder changes to dependencies) should get a revision bump
> and go through normal stabilization procedures.
> 
> 

That would be a waste of time and would increase the overall workload on
arch teams who already need 2-4 weeks to keep up with the queue. There
is no reason to re-stabilize a package after a build-time bug has been
fixed by adjusting the version of a dependency.

Moreover, the fix that was applied was very important.

Re: [gentoo-dev] Re: Changes in installed ebuilds

[hasufell]

Jörg Schaible:
> 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'm not sure if you understood the bug. It was breaking dependency
calculation of portage, so the fallout you see is minor to what was
going on.

Revbumping and restabilizing all of these packages (a LOT) would have
been unrealistic.

Another possibility would have been to revbump the ebuild and make it
instantly stable without arch teams involvement. That would actually be
the cleaner way, but afair some people don't agree with that, so it
isn't standard practice.

However, you can still overwrite tree ebuilds in your local overlay and
revert dependencies. I once did that with pypy, because it triggered too
many rebuilds for me.

Re: [gentoo-dev] Re: Changes in installed ebuilds

[Jan Matejka]

-----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-----

[gentoo-dev] Re: Re: Changes in installed ebuilds

[Jörg Schaible]

Jan Matejka wrote:

> -----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.


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

[gentoo-dev] Re: Re: Changes in installed ebuilds

[Jörg Schaible]

hasufell wrote:

> Jörg Schaible:
>> 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'm not sure if you understood the bug. It was breaking dependency
> calculation of portage, so the fallout you see is minor to what was
> going on.


The dependency calculation worked perfectly, it just could not resolve them 
anymore, because those suddenly required newer packages are hard masked on  
my system to keep the software *I* need for my daily work running.


> Revbumping and restabilizing all of these packages (a LOT) would have
> been unrealistic.


And the question was, why was the version for these deps upgraded in those 
ebuild at all. The official tree did not contain anything older anyway.

 
> Another possibility would have been to revbump the ebuild and make it
> instantly stable without arch teams involvement. That would actually be
> the cleaner way, but afair some people don't agree with that, so it
> isn't standard practice.
> 
> However, you can still overwrite tree ebuilds in your local overlay and
> revert dependencies. I once did that with pypy, because it triggered too
> many rebuilds for me.


That's what I did in the end for all "bumped" ebuilds, but the effort would 
not have been necessary at all.

- Jörg

[gentoo-dev] Re: Re: Changes in installed ebuilds

[Jörg Schaible]

hasufell wrote:

> Kristian Fiskerstrand:
>> On 06/24/2014 09:25 PM, 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.
>> 
>> 
>> For what it is worth, I completely agree significant changes to stable
>> ebuilds (hereunder changes to dependencies) should get a revision bump
>> and go through normal stabilization procedures.
>> 
>> 
> 
> That would be a waste of time and would increase the overall workload on
> arch teams who already need 2-4 weeks to keep up with the queue. There
> is no reason to re-stabilize a package after a build-time bug has been
> fixed by adjusting the version of a dependency.
> 
> Moreover, the fix that was applied was very important.


And, since the official tree did not have an older version of those deps 
anyway, the upgrade in the stable dependent ebuilds was unnecessary. It just 
broke the tree for users with local or other overlays.

- Jörg

Re: [gentoo-dev] Re: Re: Changes in installed ebuilds

[Alex Xu]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

On 25/06/14 06:42 PM, Jörg Schaible wrote:
> Except if they're locally hard masked ... ;-)

there's nothing we can do if you intentionally break your own system

>> 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.

wrong, please read the mail regarding the >= deps in the first place
which you have been referred to repeatedly.

>> 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.

broken system is broken


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: Re: Changes in installed ebuilds

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

Dnia 2014-06-26, o godz. 00:48:02
Jörg Schaible <joerg.schaible@gmx.de> napisał(a):

> hasufell wrote:
> 
> > Kristian Fiskerstrand:
> >> On 06/24/2014 09:25 PM, 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.
> >> 
> >> 
> >> For what it is worth, I completely agree significant changes to stable
> >> ebuilds (hereunder changes to dependencies) should get a revision bump
> >> and go through normal stabilization procedures.
> >> 
> >> 
> > 
> > That would be a waste of time and would increase the overall workload on
> > arch teams who already need 2-4 weeks to keep up with the queue. There
> > is no reason to re-stabilize a package after a build-time bug has been
> > fixed by adjusting the version of a dependency.
> > 
> > Moreover, the fix that was applied was very important.
> 
> 
> And, since the official tree did not have an older version of those deps 
> anyway, the upgrade in the stable dependent ebuilds was unnecessary. It just 
> broke the tree for users with local or other overlays.

But people could have older versions of those deps installed, and then
their systems would slowly become broken on upgrades. Since the issues
wouldn't be caught early properly, they would trigger incorrect
installs of another packages and a few dep-tree branches further,
an unexpected hard-to-debug failures.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

[gentoo-dev] Re: Re: Re: Changes in installed ebuilds

[Jörg Schaible]

Michał Górny wrote:

> Dnia 2014-06-26, o godz. 00:48:02
> Jörg Schaible <joerg.schaible@gmx.de> napisał(a):
> 
>> hasufell wrote:
>> 
>> > Kristian Fiskerstrand:
>> >> On 06/24/2014 09:25 PM, 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.
>> >> 
>> >> 
>> >> For what it is worth, I completely agree significant changes to stable
>> >> ebuilds (hereunder changes to dependencies) should get a revision bump
>> >> and go through normal stabilization procedures.
>> >> 
>> >> 
>> > 
>> > That would be a waste of time and would increase the overall workload
>> > on arch teams who already need 2-4 weeks to keep up with the queue.
>> > There is no reason to re-stabilize a package after a build-time bug has
>> > been fixed by adjusting the version of a dependency.
>> > 
>> > Moreover, the fix that was applied was very important.
>> 
>> 
>> And, since the official tree did not have an older version of those deps
>> anyway, the upgrade in the stable dependent ebuilds was unnecessary. It
>> just broke the tree for users with local or other overlays.
> 
> But people could have older versions of those deps installed, and then
> their systems would slowly become broken on upgrades. Since the issues
> wouldn't be caught early properly, they would trigger incorrect
> installs of another packages and a few dep-tree branches further,
> an unexpected hard-to-debug failures.

OK, you have a point. However, it is more dependent on the way people use 
emerge. This scenario could not have happen to me, I call emerge always 
with:

   emerge -uDvta --changed-use --with-bdeps=y

Cheers,
Jörg