[Bug 243032] New: possible /opt/gnome -> /usr upgrade problems with ld.so.conf
https://bugzilla.novell.com/show_bug.cgi?id=243032 Summary: possible /opt/gnome -> /usr upgrade problems with ld.so.conf Product: openSUSE 10.3 Version: Alpha 0plus Platform: All OS/Version: All Status: NEW Severity: Normal Priority: P5 - None Component: GNOME AssignedTo: bnc-team-gnome@forge.provo.novell.com ReportedBy: andreas.hanke@gmx-topmail.de QAContact: qa@suse.de /opt/gnome/lib has been removed from /etc/ld.so.conf. Instead, there is /etc/ld.so.conf.d/opt_gnome-compat.conf now. This will cause a problem during a system upgrade if the following happens: - glibc is updated first - Next, a package that calls a GNOME binary in one of its rpm scriptlets is updated before all the libraries have been moved to /usr, and before gnome-filesystem is replaced by opt_gnome-compat There are also a few other ld.so related issues with opt_gnome-compat: - It does not run /sbin/ldconfig in its %post scriptlet, but it has to, otherwise ld.so will not see the libraries in /opt/gnome/lib even if they are present in the filesystem - /opt/gnome/lib is missing on x86_64, just /opt/gnome/lib64 is there. This will break 32bit /opt/gnome packages. It was present in glibc until 10.2. x86_64 needs both. ppc64 might need both, too. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=243032 ------- Comment #1 from sbrabec@novell.com 2007-02-07 11:28 MST ------- I can imagine a fix: new glibc can contain Conflicts: gnome-filesystem. But we must check twice, whether it will not introduce any dependency loops, because opt_gnome_compat contains Conflicts for old gconf2 version. If resolver can allow update of gconf2 as the first package (even before glibc), then it can work. If not, we can use ugly trick in opt_gnome_compat - use %ghost for gconftool-2 and create it by one-time SuSEconfig. I agree with the remaining problems. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=243032 sbrabec@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |schubi@novell.com ------- Comment #2 from sbrabec@novell.com 2007-02-08 03:39 MST ------- We a entering to a real dependency hell. Stefan, can you advice with the dependency tree? Comments to the attached image: - My proposed solution is a conflict of the new glibc with (old) gnome-filesystem. - I can get rid the conflict opt_gnome-compat x old gconf2. The need is: If gnome-filesystem is installed, then update it to opt_gnome-compat before glibc. If we don't do it, uninstallation scriptlets of old instances will probably fail. Package opt_gnome-compat is optionally deleted in SuSEconfig. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=243032 ------- Comment #3 from sbrabec@novell.com 2007-02-08 03:40 MST ------- Created an attachment (id=118032) --> (https://bugzilla.novell.com/attachment.cgi?id=118032&action=view) gnome-update.png Update dependency tree. Left is 10.2, right is 10.3. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=243032 schubi@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Info Provider|schubi@novell.com |ro@novell.com ------- Comment #4 from schubi@novell.com 2007-02-14 10:00 MST ------- I do not understand the problem completely, but a package which uses GNOME bins in his scripts must ensure that GNOME is *complete* runable ( defined with prerequires). The new dependency "reverse prerequire" does not exists. Rudi, can you help here ? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=243032 ------- Comment #5 from sbrabec@novell.com 2007-02-14 10:14 MST ------- Yes. Our problem is, that uninstallation scriptlets (namely SLES9 gstreamer scriptlets) are not runable, even if their RPM requiremens are filfiled. The reason: Packages cannot find any more libraries still present in /opt/gnome/lib, if glibc is updated and opt_gnome-compat is not yet present. I can imagine adding Conflicts: gnome-filesystem to glibc, but I am not sure, whether it forces early installation of opt_gnome-compat, which provides gnome-filesystem. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=243032 ------- Comment #6 from kukuk@novell.com 2007-02-15 01:42 MST ------- The solution is simple: let /opt/gnome in ld.so.conf itself and don't move it to another place. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=243032 ------- Comment #7 from andreas.hanke@gmx-topmail.de 2007-02-15 03:27 MST ------- Trying to solve this via dependencies can result in a dependency loop. gconf2 is an ELF binary and glibc has versioned symbols. Therefore, gconf2 will sooner or later require the latest glibc because it is always rebuilt against the latest glibc. => glibc has to be updated before gconf2. glibc does not provide /opt/gnome/lib any more, opt_gnome-compat does. => opt_gnome-compat has to be updated before glibc. opt_gnome-compat provides /opt/gnome/bin/gconftool-2 and therefore conflicts with old versions of gconf2. => gconf2 has to be updated before opt_gnome-compat. In the end, every package has to be updated before the other one, which is somewhat difficult: opt_gnome-compat before glibc glibc before gconf2 gconf2 before opt_gnome-compat -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=243032 ------- Comment #8 from kukuk@novell.com 2007-02-15 03:32 MST ------- So again, the answer is simple: Don't move /opt/gnome from ld.so.conf to another config file. I don't see what this move should solve. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=243032 ------- Comment #9 from andreas.hanke@gmx-topmail.de 2007-02-15 04:06 MST ------- The move helps getting rid of /opt/gnome entirely. If /opt/gnome/lib is in ld.so.conf and libtool gets rebuilt against it, libtool will consider /opt/gnome/lib a "system path" and not hardcode it into programs, making it more difficult to get rid of it. It also makes sure that /opt/gnome/lib is searched after /usr/lib and not before. This can help preventing problems like bug 235626. On x86_64 the same effect can be achieved by reordering ld.so.conf, but on i586 this is not possible because it does not contain /usr/lib at all. (In reply to comment #1)
If resolver can allow update of gconf2 as the first package (even before glibc), then it can work.
No, this is (at least in the long run) exactly the place where it does not work because as glibc gets updated and gconf2 rebuilt against it, gconf2 will require a more recent glibc. Can YaST help here? /etc/ld.so.conf.d/opt_gnome-compat.conf could be created by YaST and later overwritten by opt_gnome-compat (or deleted if not needed). Something like this: if ...check whether this is an update... ; then echo /opt/gnome/lib > /etc/ld.so.conf.d/opt_gnome-compat.conf /sbin/ldconfig fi ..do the update... if ! rpm -qf /etc/ld.so.conf.d/opt_gnome-compat.conf ; then rm -f /etc/ld.so.conf.d/opt_gnome-compat.conf /sbin/ldconfig fi -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=243032 ------- Comment #10 from sbrabec@novell.com 2007-02-15 04:10 MST ------- After successful upgrade, /etc/ld.so.conf.d/opt_gnome-compat.conf (and the whole opt_gnome-compat package) will be deleted, unless there is any third party application in /opt/gnome. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=243032
------- Comment #11 from sbrabec@novell.com 2007-02-15 04:33 MST -------
Possible work-around in glibc:
%post
# This script is required for <=openSUSE10.2 and <=SLES10 upgrade protection.
# Are we upgrading from < 10.3?
if test -f etc/profile.d/gnome-filesystem.sh ; then
echo /opt/gnome/lib >etc/ld.so.conf.d/glibc-temp.conf
cat >sbin/conf.d/SuSEconfig.glibc-temp <
https://bugzilla.novell.com/show_bug.cgi?id=243032 ------- Comment #12 from kukuk@novell.com 2007-02-15 05:24 MST ------- (In reply to comment #9)
The move helps getting rid of /opt/gnome entirely. If /opt/gnome/lib is in ld.so.conf and libtool gets rebuilt against it, libtool will consider /opt/gnome/lib a "system path" and not hardcode it into programs, making it more difficult to get rid of it.
Ok, libtool is broken. But this is nothing new. And new applications should not use /opt/gnome at all, I really think we can ignore this case. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=243032 sbrabec@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team- |sbrabec@novell.com |gnome@forge.provo.novell.com| Status|NEEDINFO |ASSIGNED Info Provider|ro@novell.com | ------- Comment #13 from sbrabec@novell.com 2007-02-28 05:47 MST ------- Assigning to me. Last time I tried 10.2->10.3 upgrade I didn't see any breakage caused by this problem. Work-around from comment 11 has a bad check - gnome-filesystem gets deleted first while upgrading. This may differ for NLD9->SLED11, where there are present gstreamer scriptlets. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
participants (1)
-
bugzilla_noreply＠novell.com