Font packages changes required for dropping chkfontpath/xfs

[Tom Lane]

Pete Zaitcev <zaitcev at redhat.com> writes:
> On Mon, 06 Aug 2007 19:32:13 -0400, Tom Lane <tgl at redhat.com> wrote:
>> I can think of a number of cases where [a relative symlink would]
>> be a bad idea, and none where it really solves a problem.

> I'd like to hear how a relative symlink can be a bad idea.
> It seems obvious to me that all symlinks should be relative,
> but equally obviously I'm forgetting something. What do you have
> in mind?

Well, aside from the PITA factor of setting it up (how do you determine
the number of ".."s to use), there are a couple of things that make me
not want to do it that way:

1. Can't move the referencing package's contents around, at least not up
or down any directory levels.

2. The symlink will be actively wrong while doing the RPM build/install,
because it won't account for the BuildRoot: directories.  I don't
currently try to do any active testing on the post-%install fileset,
but if I did it would not work with a relative symlink.

The counterexamples you mention are interesting but don't seem
particularly relevant to a read-only reference to a standard system
directory.

I entirely agree that relative symlinks are appropriate for
cross-references between parts of a single software package.
I'm not convinced about references to system components that
are unrelated to the package doing the referencing.

			regards, tom lane