[gs-bugs] [Bug 698814] - Ghostscript - [RFE] Enable the --docdir= parameter to start working

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698814

Bug ID: 698814
Summary: [RFE] Enable the --docdir= parameter to start working
Product: Ghostscript
Version: master
Hardware: PC
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P4
Component: Config/Install
Assignee: ghostpdl-***@artifex.com
Reporter: ***@redhat.com
QA Contact: gs-***@ghostscript.com
Word Size: ---

Created attachment 14530
--> http://bugs.ghostscript.com/attachment.cgi?id=14530&action=edit
enable-docdir-parameter.patch

Hello guys,

this changes fixes the --docdir= parameter of ./configure as discussed
previously on IRC.

Previously, the Ghostscript was using custom path to the documentation (as
docdir=$(gsdatadir)/doc). This was causing that value of --docdir= parameter of
./configure was accepted, but not used at all.

This commit fixes this issue, by using docdir=@docdir@@VERSIONED_PATH@ instead.
However, as a side effect this results in default path for documentation to

/usr/share/doc/ghostscript/<version>/

To stay backward compatible, a symlink is automatically created to point from
the old location (/usr/share/ghostscript/<version>/doc) to the new location.

Because we're referencing the @VERSIONED_PATH@ already in this change, this BZ
is dependent on BZ #698795, which should be merged/included first.

IMHO, this is the only sensible way of trying to resolve thix issue. Trying to
fix this issue with the location of documentation staying as it was would
require some hacking inside the Autoconf itself, which is not desirable.

NOTE:
I have tested these changes and they work correctly. But saw a strange

make install soinstall

In this case the patch itself works as intended, but one more symlink is being
created as a result of this:

/usr/share/doc/ghostscript/<version>/<version> ->
/usr/share/doc/ghostscript/<version>/

After fiddling with this a little it seems to happen when both targets
'install' and 'soinstall' are used (even separately). My testing shows that
@VERSIONED_PATH@ is not causing this. It is caused by the change in this commit
(the symlink creation).

It seems to me there's some magic with paths going on in the background when
issuing both of these Makefile targets, resulting in one more symlink being
created.

In this case the question is - is this even supported usecase? And do you
consider this to be a problem?

If yes, I could try to come up with some solution for this if needed.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698814

Hin-Tak Leung <***@users.sourceforge.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@users.sourceforge.net

--- Comment #1 from Hin-Tak Leung <***@users.sourceforge.net> ---
Since you have a @redhat address, I assume this change will eventually filtered
into the rpm package that redhat provides.

You are aware that the rpm packaging system cannot cope with upgrades where
directories are changed into symlinks and vice versa (without some extra hack
in post-install/pre-install scripts)? You can check redhat's own bugzilla on
it...

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698814

--- Comment #2 from David Kaspar [Dee'Kej] <***@redhat.com> ---
Hello Hin-Tak,

(In reply to Hin-Tak Leung from comment #1)

filtered into the rpm package that redhat provides.

For now this change is intended for Fedora, where it is needed most. But yes,
it will make it into RPM package.

You are aware that the rpm packaging system cannot cope with upgrades where
directories are changed into symlinks and vice versa (without some extra
hack in post-install/pre-install scripts)? You can check redhat's own
bugzilla on it...

Actually, I'm not aware of it. Could you please share the BZ link if you have
it? I would be surprised if this is still an issue for RPM.

Thank you!

-- Dee'Kej --

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698814

--- Comment #3 from Hin-Tak Leung <***@users.sourceforge.net> ---
(In reply to David Kaspar [Dee'Kej] from comment #2)
...

Post by b***@artifex.com
Actually, I'm not aware of it. Could you please share the BZ link if you
have it? I would be surprised if this is still an issue for RPM.

...

Here you are.
https://bugzilla.redhat.com/show_bug.cgi?id=447156

I joined the cc at comment 33. It was still a problem 9 months ago and AFAIK,
no progress.