Bug 23018

Summary:	Bad package order if older versions is required
Product:	Portage Development	Reporter:	Stanislav Brabec <utx>
Component:	Unclassified	Assignee:	Portage team <dev-portage>
Status:	RESOLVED DUPLICATE
Severity:	major	CC:	foser
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Bug Depends on:
Bug Blocks:	21754

Description Stanislav Brabec 2003-06-17 14:00:46 UTC

Suppose I want to merge following packages: latest gtk+, but older version of
glib. We know, that gtk+ depends on glib and glib-2.2.1-r1 is sufficiently new
for gtk+-2.2.1-r1.

emerge --pretend --oneshot --emptytree =x11-libs/gtk+-2.2.1-r1
=dev-libs/glib-2.2.1-r1

Output contains following interesting lines (in order):
[ebuild  N   ] dev-libs/glib-2.2.2
[ebuild  N   ] x11-libs/gtk+-2.2.1-r1
[ebuild  N   ] dev-libs/glib-2.2.1-r1

It means, that required version glib is installed _AFTER_ gtk+. In this
particular case it does not break anything, but principially it's bad - in case
that required older version has different soname, it can potentially break gtk+.

Comment 1 foser (RETIRED) gentoo-dev

2003-06-18 05:06:37 UTC

No i think this is expected behaviour, in case you give seperate emerge options they will be processed seperatly and in order afaik. So first processed is gtk+, which has no restraints and next you pick a lower glib then the one gtk+ depsearch comes up with. Since you know gtk needs glib, you should have put the deps in the right order in the first place : 'ACCEPT_KEYWORDS=~x86 emerge --pretend --oneshot --emptytree =dev-libs/glib-2.2.1-r1 =x11-libs/gtk+-2.2.1-r1' which results in the behaviour you would like to see.

I'm sure you could break stuff like this, but you are deliberatly trying to. Portage should then always check of every installed package if it depends on the lib updated(downgraded) and maybe even rebuild (downgrade) toplevel packages as needed. But i don't think these sort of safety precautions is a) needed b) worth the time it takes currently . There is some responsibility on the user side to know what he/she is messing with and take the problems that come from it.

Anyway bug-wranglers, this is in essence a portage problem. Please close or reassign as you see fit ( i think this is a problem we are aware of and it isn't necessary to file as a new bug ).

As a last note, there are many known deficiencies in portage, bringing them up without a solution (code) isn't helping much.

Comment 2 Seemant Kulleen (RETIRED) gentoo-dev

2003-06-18 06:22:00 UTC

closing

Comment 3 Jason Stubbs (RETIRED) gentoo-dev

2005-10-07 03:09:25 UTC


*** This bug has been marked as a duplicate of 1343 ***