Bug 448911 - file conflict between ia64/i386 versions of pam
Summary: file conflict between ia64/i386 versions of pam
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: pam   
(Show other bugs)
Version: 4.7
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact:
Keywords: Reopened
Depends On: 449734
TreeView+ depends on / blocked
Reported: 2008-05-29 13:42 UTC by Alexander Todorov
Modified: 2008-10-03 11:54 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-03 11:54:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Comment 1 Tomas Mraz 2008-05-29 14:11:27 UTC
This is not a regression in the pam package. These files were always different
between ia64 and i386 pam package. Perhaps something else changed between 4.6
and 4.7? rpm possibly?

Comment 2 Alexander Todorov 2008-05-29 14:49:21 UTC
This is a regression in pam. For example the conflicting file above

is present in the ia64 and i386 version in RHEL4/U6 and doesn't conflict.

The diff between the same file in 4.7 is:

--- pam_modules.ps.ia64 2008-03-27 13:52:25.000000000 +0100
+++ pam_modules.ps.i386 2008-03-27 13:42:49.000000000 +0100
@@ -8,10 +8,10 @@
 %DVIPSWebPage: (www.radicaleye.com)
 %DVIPSCommandLine: dvips -R -q -t letter -o
-%+ /tmp/linuxdoc-dir-15919/sgmltmp.pam_modules-latex-15919.dir/pam_modules.ps
+%+ /tmp/linuxdoc-dir-2234/sgmltmp.pam_modules-latex-2234.dir/pam_modules.ps
 %+ pam_modules.dvi
 %DVIPSParameters: dpi=600, compressed
-%DVIPSSource:  TeX output 2008.03.27:0852
+%DVIPSSource:  TeX output 2008.03.27:0842
 %%BeginProcSet: texc.pro
 /TeXDict 300 dict def TeXDict begin/N{def}def/B{bind def}N/S{exch}N/X{S

clearly they don't differ in content.

Comment 3 Tomas Mraz 2008-05-29 15:04:18 UTC
This is NOT a regression in PAM - look at the pam-0.77-66.23 (version from RHEL4/U6)
these files were always different between architectures.

Comment 4 Panu Matilainen 2008-05-29 16:44:25 UTC
The conflict might have always been there, it's just that in RHEL 4.7 rpm no
longer completely ignores them. Previously all sorts of checking was skipped for
large number of directories, such as docdirs, translations etc.

Comment 5 Tomas Mraz 2008-05-30 07:14:00 UTC
Yes, that's what I expected. Unfortunately to solve this problem the pam package
would have to be changed to split out the documentation into a separate
subpackage. Would that be appropriate for RHEL-4.7 package? When the public beta
is already out so possible problems with this split will not be found by public

It was really unfortunate to introduce this kind of change into RHEL-4.7 rpm
without doing thorough check of shipped packages for conflicts in advance. We
could fix them appropriately and with appropriate amount of testing, not this
late in the RHEL-4.7 development cycle.

Comment 7 Alexander Todorov 2008-05-30 09:12:10 UTC
Bugs exhibiting this issue:
bug #448905, bug #448906, bug #448907, bug #448909, bug #448910, bug #448911

Comment 9 Alexander Todorov 2008-06-10 15:55:13 UTC
Update: seeing this also on ppc. 

pam.ppc is installed by default where pam.ppc64 is not. When trying to install
pam.ppc64 we have the same file conflict. 

Comment 10 RHEL Product and Program Management 2008-09-05 17:04:53 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 11 Tomas Mraz 2008-10-03 11:54:13 UTC
As rpm is fixed to not report this conflict and the fix would require to create a subpackages I do not think this is appropriate for RHEL-4.8.

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