Bug 166441 - man page conflict with xscreensaver-extras
man page conflict with xscreensaver-extras
Product: Fedora
Classification: Fedora
Component: xscreensaver (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
: 182304 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-08-21 11:11 EDT by Toshio Kuratomi
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-08-26 13:30:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Toshio Kuratomi 2005-08-21 11:11:14 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
The xscrensaver-extras package cntains a barcode screensaver module with a man page: /usr/share/man/man1/barcode.1.gz

The barcode package contains a manpage wih the same name for the binary front-end that generates postscript from a barcode description.

The naming of one of these has to change so both packages can be installed.

Version-Release number of selected component (if applicable):
barcode-0.98-7.fc4; xcscreensaver-extras-4.21-4

How reproducible:

Steps to Reproduce:
1. yum install xscreensaver-extras
2. yum install barcode

Actual Results:  Running Transaction Test
Finished Transaction Test
Transaction Check Error:   file /usr/share/man/man1/barcode.1.gz from install of barcode-0.98-7.fc4 conflicts with file from package xscreensaver-extras-4.21-4

Expected Results:  barcode installs

Additional info:
Comment 1 Andreas Thienemann 2005-08-21 13:51:52 EDT
Ray, do you think it's possible to rename the xscreensaver barcode command/man
page? How much hassle would that be?
FHS says, both manpages should go into /usr/share/man/man1, which means we'll
have conflicting files until one manpage is removed/renamed.

Comment 2 Ray Strode [halfline] 2005-08-21 23:49:58 EDT
Hi Andreas,
This type of conflict has happened before with the "ant" screensaver (and the
"ant" java unit testing tool.

Jamie, what do you think we should do?
Comment 3 Jamie Zawinski 2005-08-22 05:49:37 EDT
> Jamie, what do you think we should do?
Comment 4 Jamie Zawinski 2005-08-22 05:53:25 EDT
> Jamie, what do you think we should do?

Didn't you get my mail about this (maybe a week ago?)  I think the easy fix for the "ant" problem is to just 
not install the "ant" screen saver or man page.  It's kinda lame anyway.

I thought xscreensaver man pages were getting installed into section 6 ("games"), not section 1?

(Sorry about the previous comment spaz. Damned non-emacs keybindings...)
Comment 5 Ray Strode [halfline] 2005-08-22 09:54:04 EDT
Hi Jamie,

My point is this same problem is happening again with the "barcode" screensaver.
Should we just disable it, too, or come up with a better solution?
Comment 6 Andreas Thienemann 2005-08-22 10:13:58 EDT
For the short term, putting the xscreensaver manpages into man6 might be viable.
On the other hand, renaming them xscreensaver-ant and xscreensaver-barcode might
be not a bad idea either. Prepending them with xscreensaver- should prevent any
conflicts in the future. 
Comment 7 Ray Strode [halfline] 2005-08-22 10:30:13 EDT
Hi Andreas,

The short-term fix of moving to man6 will work for Fedora, but not upstream. 
You see xscreensaver checks $PATH when looking for the actual screensaver
binaries, so if the user doesn't have xscreensaver-extras installed and they do
have barcode installed then it will show up in the screensaver list and fail
when xscreensaver tries to use it as a screensaver.

Unfortunately namespacing the screensavers causes upgrade problems.
Comment 8 Jamie Zawinski 2005-08-24 22:25:59 EDT
I think the man pages should go in section 6; that will result in no rpm conflicts (since xscreensaver 
binaries already go into /usr/libexec/xscreensaver/)

Renaming all of the xscreensaver binaries to be e.g., "xscreensaver-glmatrix" and so on would be 
horrible.  Not only are those stupidly long names, but it would break every single ~/.xscreensaver file 
out there.

The current problem is that, if no screensavers are installed, it may look like the "barcode" saver is 
installed.  That's bad, but it's not horrible, since the user will pretty clearly notice that the one-and-only 
apparently-installed saver doesn't actually work.  (And with that patch I sent you the other day, 
"xscreensaver-demo" will point out that "xscreensaver-extras" is not installed in that case, anyway.)

So renaming the binaries seems like a case where the cure is far, far worse than the problem.  I'm 
inclined to just ignore it.

We could make xscreensaver set $PATH to the libexec directory only.  That would mean that any 3rd-
party savers would have to go in that same directory, and not in /usr/local/bin or whatnot, which would 
be irritating, but maybe not terrible.  However we'd then also have to move all the helper apps, like 
xscreensaver-getimage-file, so that they could still be found by the savers.  I think they would still be 
able to find /usr/bin/perl because of the #! line, even if perl wasn't on $PATH, right?  Hmmm...

Oh, and that would totally break any savers that rely on other non-bundled progams, like vidwhacker 
(which requires the full gammut of pbm tools).

So, yeah, shrinking $PATH to only the libexec directory seems like a bad idea, too.

Bringing me back to my original plan: "ignore the problem".
Comment 9 Toshio Kuratomi 2005-08-25 02:53:12 EDT
I thought I had found a way to work around Comment #8 by setting different PATHs
for loading the list of hacks vs invoking the hacks but it turns out I can't get
the problem to show itself at all.  I've tried:
1) editing the cvs devel spec file to remove all patches and rebuilding.
2) Install this xscreensaver-base
3) Install barcode
4) Run xscreensaver-demo
5) Notice that there is no entry for barcode....

This is not what I expected but is what we want.  Is there some other magic
going on in the spec besides the patches that could lead to this or are we
worrying over non-issues?

PS -- It seems that the literal object of this bug could be resolved simply by
shifting the man pages to section 6 regardless of fixing the display when a
binary with the same name as a screensaver is installed.
Comment 10 Ray Strode [halfline] 2005-08-25 09:44:43 EDT
Hi Toshio,

Fedora currently has a patch to xscreensaver that specifies the absolute path of
screensavers instead of just the basenames.  That's why you can't reproduce the

Even though you removed the patches, you probably still have an ~/.xscreensaver
file with the patched filenames in it.

Note the patch isn't going to go upstream, so it will probably be dropped the
next time a new xscreensaver release comes out.

Well we can worry about the phantom barcode screensaver problem later.  For now
i'll just move the man pages to section 6.
Comment 11 Andreas Thienemann 2005-08-25 10:42:38 EDT
Thanks ray.
I'm reassigning the bug to you.

In the long term, we should definitly think about a way of preventing these
conflicts. With fedora-extras, the number of potential conflicts can only rise...
Comment 12 Ray Strode [halfline] 2005-08-26 13:30:59 EDT

I've moved the man pages to section 6 in rawhide.
Comment 13 Andreas Thienemann 2006-02-21 14:24:40 EST
*** Bug 182304 has been marked as a duplicate of this bug. ***

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