Bug 399 - Upgrade does not work with absolute symbolic links
Summary: Upgrade does not work with absolute symbolic links
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 5.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matt Wilson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1998-12-12 18:31 UTC by ppe
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-03-31 23:12:42 UTC
Embargoed:


Attachments (Terms of Use)

Description ppe 1998-12-12 18:31:20 UTC
I just upgraded from 5.1 to 5.2 and encountered the
non-trivial problem of having the symbolic links
  /var/lib -> /usr/links/var/lib
  /var/tmp -> /usr/links/var/tmp
which caused the upgrade to fail (could not find the
rpm database). Although the failure was caused
by having installed *absolute* links (my fault),
it would be nice, if the installer would work around this
(e.g by doing chroot). Changing the links to relative
links solved the problem. Maybe this should be done
automatically by the installer? At least the installer
should be able to detect the problem and give a proper
error message.
Cheers, Peter.

Comment 1 David Lawrence 1998-12-13 23:54:59 UTC
This has been assigned to a developer for further review.

Comment 2 Matt Wilson 1999-01-12 03:47:59 UTC
Fixing this would be very hard - involving walking trees and resolving
symlinks.  I never use absolute symlinks to avoid problems with
chroot()'ed operations.

Comment 3 ppe 1999-01-19 19:24:59 UTC
Actually the big problem was that `rpm' could not find the
rpm database. Maybe it is possible to use the `--root' switch
for this? An absolute link should than point to the
right place. For doing this, you probably just have to change
in the file upgrade.c:

:::line 395:::
int ugFindUpgradePackages(struct pkgSet *psp, char *installRoot)
{
    rpmdb db;
    struct hash_table *hashTable;

    logDebugMessage(("ugFindUpgradePackages() ..."));

    rpmReadConfigFiles(NULL, NULL, NULL, 0);

[[[ here you should insert something to find out what `installRoot'
    should be, e.g. by reading the possible symbolic link info of
    var, lib, and rpm to construct a new unsymbolic path ]]]


    if (rpmdbOpen(installRoot, &db, O_CREAT | O_RDWR, 0644)) {
	logMessage("failed opening %s/var/lib/rpm/packages.rpm",
		     installRoot);
[[[ here you could add a comment, that this error may be caused
    by an absolute link in the path /var/lib/rpm ]]]
	return(INST_ERROR);
    }

---------------------Just a comment:
BTW, there are some rpm files which do not install with
relative links. One simple example is `xbill'. It installs
symbolic links like:
   cd /var/lib/games/xbill
   ln -s ../../../../usr/lib/xbill/bitmaps bitmaps
Now, if /var/lib is a relative symbolic link, e.g.:
   cd /var
   ln -s ../usr/links/var/lib lib
(say a user wants to keep all modifications at a special place
/usr/links)
than the xbill.rpm installs without errors but the bitmaps link is
dangling.
It works, however, if the /var/lib link is in the same depth, e.g.:
   cd /var
   ln -s ../usr/varlib lib
----------------------

Best Wishes, Peter.

Comment 4 Erik Troan 1999-03-31 23:12:59 UTC
/var/lib and /tmp must be relative links; fixing this would be
quite involved and isn't worth the trouble


Note You need to log in before you can comment on or make changes to this bug.