Bug 166441

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.

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?

> Jamie, what do you think we should do?

> 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...)

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?

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. 

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.

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".

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.

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
problem.  

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.

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...

Hi,

I've moved the man pages to section 6 in rawhide.

*** Bug 182304 has been marked as a duplicate of this bug. ***