Bug 472617 - Conflict with pssh
Conflict with pssh
Product: Fedora
Classification: Fedora
Component: pssh (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Terje Røsten
Fedora Extras Quality Assurance
Depends On:
Blocks: 485969
  Show dependency treegraph
Reported: 2008-11-21 20:56 EST by Michael Schwendt
Modified: 2012-02-18 12:22 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-11-05 13:14:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
alternatives patch for pssh. (1.31 KB, patch)
2009-03-01 09:36 EST, Terje Røsten
no flags Details | Diff

  None (edit)
Description Michael Schwendt 2008-11-21 20:56:38 EST
  File conflict with: pssh-1.4.0-1.fc10.noarch
Comment 1 Bug Zapper 2008-11-26 00:45:43 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
Comment 2 Hans Ulrich Niedermann 2009-02-01 08:02:30 EST
Confirmed in F10 release, with
Comment 3 Hans Ulrich Niedermann 2009-02-20 08:53:11 EST
Are there any putty maintainers alive and reading bug reports?
Comment 4 Terje Røsten 2009-03-01 09:34:09 EST
Should we use alternatives to fix this issue? 

Going down that path, here is a patch for pssh.

You can use it to adapt putty. 

I used priority 50 for pssh, you can choose if you want putty to be higher or lower.

Please ping if doing the change.
Comment 5 Terje Røsten 2009-03-01 09:36:54 EST
Created attachment 333647 [details]
alternatives patch for pssh.

patch for comment #4.
Comment 6 Patrick Laughton 2009-06-11 10:46:48 EDT
I'm sorry, but how on earth did pssh pass review if it conflicts with putty, which has been in Fedora (Extras) 5 years longer?

I apologize for overlooking this bug until now.
Comment 7 Michael Schwendt 2009-06-14 05:32:42 EDT
Nothing in the Fedora Review process requires reviewers to check for conflicts. 
There's not even a guideline that suggests checking for potential conflicts (such as poorly chosen filenames in overloaded namespaces). There is no tool that performs automatic checks against all of Fedora. There's only repoquery and similar.

One consequence is that even some duplicate packages have entered the package collection. Once with old name and old version, a second time with new name and new version. ;)
Comment 8 Patrick Laughton 2009-06-14 13:35:28 EDT
From http://fedoraproject.org/wiki/Packaging/ReviewGuidelines :

MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time.

Maybe our interpretations of that guideline aren't the same, but that's how I read it.

Regardless of the letter (or spirit) of the policy, I find it genuinely dishonest that it was claimed that such a verification was performed (see https://bugzilla.redhat.com/show_bug.cgi?id=460044#c3 ):

[x] Package does not own files or directories owned by other packages.

This suggests to me that we may be guilty of incomplete, cookie-cutter reviews, which is a very concerning implication.
Comment 9 Michael Schwendt 2009-06-14 14:36:31 EDT
I'm aware of those guidelines (I still do reviews occasionally). I bet the majority of reviewers only apply that item to a package's set of sub-packages (as in "avoiding files to be included in multiple sub-packages") and at most check whether a package is included with Fedora already, because as I pointed out there are no tools to compare an arbitrary package against a set of remote repositories [other than my script on my people page, which is only for advanced users].  I don't mean to defend reviewers, who don't discover implicit conflicts. There's just no evidence (such as reviews with quoted shell session output) that reviewers do more than checking that packages don't own "filesystem" or "man" directories, and not even that. Too many reviewers (as well as packagers) need step-by-step recipes on how to check something. The guidelines don't explain _how to_ meet the requirements of this MUST item, and additionally, they leave room for (mis-)interpretation.

What you write in the bottom of your comment 8 is something I agree with, but beyond that I don't comment on it here in bugzilla.
Comment 10 Terje Røsten 2009-06-14 16:02:25 EDT
Could we please stop this ranting and fix the bug instead? 
We have wasted 6 months allready...
Comment 11 Patrick Laughton 2009-06-14 16:57:33 EDT
Yes, I would like to see this fixed.
Comment 12 Terje Røsten 2012-02-18 12:22:00 EST
Hi putty maintainers, 

is putty is active? I am looking into fixing #794567.

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