[Bug 238655] New: incomplete directory ownership checks
https://bugzilla.novell.com/show_bug.cgi?id=238655 Summary: incomplete directory ownership checks Product: openSUSE 10.3 Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: sbrabec@novell.com QAContact: qa@suse.de Either Autobuild or RPM does not implement directory ownership checks correctly. We have a strict policy about directory ownership, but not a strict policy about directory ownership dependencies. It allows to delete gnome-filesystem package even if directories owned by it are still not empty and packages use it. Currently, there is implemented a check, which verifies, that all directories in the build root have its owners. But it's insufficient for preventing orphan directories. It seems, that any package has to depend (by Requires or even PreReq) on all other packages that own directories, where package install its files and directories. It may be implemented by AutoReqProv, but such attempt will be complicated by multiple directory ownership. As a consequence, we will have a problem with deleting of /opt/gnome. How to reproduce: Suppose you have a Factory base installed Install 10.2's gnome-filesystem Install 10.2's gnome-mag remove gnome-filesystem Upgrade to 10.3's gnome-mag Now look for example /opt/gnome/share/idl. This directory is owned by gnome-filesystem and should not exist, but it exists and is empty. Dependency tree was correct in 10.2: gnome-mag requires (implicitly) glib2, glib2 requires gnome-filesystem Dependency tree is correct in 10.3. We have a problem, that after glib2 update, gnome-filesystem can be deleted, even if gnome-mag is not yet updated. Proposed work-around: The best candidate to obsolete gnome-filesystem is glib2 as the lowest level former-/opt/gnome package. But it is possible to delete gnome-filesystem package even if directories owned by it are still not empty and packages use it. As a result, it will cause orphaned directories. That's why I propose a tricky solution: gnome-filesystem package has a very special one-time SuSEconfig scriptlet. This scriplet needs a new host - probably glib2. If it is possible (i. e. rpm database is unlocked during SuSEconfig), it would be the best solution to do "rpm -e gnome-filesystem" there, in time, when all packages in /opt/gnome will be away. Another possible solution: install opt-gnome-compat, check, whether /opt/gnome is empty in SuSEconfig. If yes, delete opt-gnome-compat, if not, keep it there. It will allow to continue with using of third party /opt/gnome packages. Andreas Jaeger wrote:
That's a hack :-(
Yes, it is. But it can work, as one could expect (/opt/gnome will disappear in SuSE-only installation and will continue to be supported, if third party package is installed there). -- 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=238655 ------- Comment #1 from mls@novell.com 2007-01-26 11:04 MST ------- I think the best way is just to live with the orphaned directory. -- 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=238655 ------- Comment #2 from sbrabec@novell.com 2007-01-29 04:31 MST ------- Older versions of SuSEconfig have had a hack to purge orphaned directories after upgrade from /opt/gnome2 to /opt/gnome. I am thinking about recycling them. -- 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