I'm trying to do an update to some servers... and they have both i386 and x86_64 perl. The latter won't update, because the idiotic *man pages* are dups. Is there *any* way, short of using rpm directly with a --force, to get yum to ignore the dups and do the update?
And why does *anyone* make it so that a dup manpage is a reason to fail (and don't tell me they do it generically for any of the packages in the .rpm...)?
mark
On 06/16/2010 06:10 AM, m.roth@5-cent.us wrote:
I'm trying to do an update to some servers... and they have both i386 and x86_64 perl. The latter won't update, because the idiotic *man pages* are dups. Is there *any* way, short of using rpm directly with a --force, to get yum to ignore the dups and do the update?
Yes, this is frustrating. I've encountered it a number of times while packaging perl modules that override those in the core (e.g. Test::More). Sorry, but I've never found a really good solution beyond --force or --replacefiles.
And why does *anyone* make it so that a dup manpage is a reason to fail (and don't tell me they do it generically for any of the packages in the .rpm...)?
Thinking this through from the rpmdb's perspective, which of the two packages 'owns' the man pages. If you were to, say,
rpm -e perl.i386
would you expect it to remove the man pages or not. What would you expect
rpm -V perl
to report in either case. As far as I'm aware there is no such 'duplication' logic in the db. It would be cool if it could be made to work in general, however, I can think of some use cases that might rule this out. By using --force (or --replacefiles) you are effectively breaking the consistency of the install/upgrade/remove logic and yum should protect you from doing that by accident.
Stepping back a bit, why do you need both perl.i386 and perl.x86_64 packages? Which package 'owns' the /usr/bin/perl executable? None of my Centos 5 x86_64 systems have both and they have all gone through a recent perl upgrade, so I'm curious how you got both installed in the first place. Is there some dependency that pulled in the i386 package?
Kal
On 6/15/10 3:26 PM, "Kahlil Hodgson" kahlil.hodgson@dealmax.com.au wrote:
On 06/16/2010 06:10 AM, m.roth@5-cent.us wrote:
I'm trying to do an update to some servers... and they have both i386 and x86_64 perl. The latter won't update, because the idiotic *man pages* are dups. Is there *any* way, short of using rpm directly with a --force, to get yum to ignore the dups and do the update?
Yes, this is frustrating. I've encountered it a number of times while packaging perl modules that override those in the core (e.g. Test::More). Sorry, but I've never found a really good solution beyond --force or --replacefiles.
This is the EXACT reason I use site_perl instead of vendor_perl prefixes for Perl modules that are not packaged by upstream for the internal repo we have here.
And why does *anyone* make it so that a dup manpage is a reason to fail (and don't tell me they do it generically for any of the packages in the .rpm...)?
Thinking this through from the rpmdb's perspective, which of the two packages 'owns' the man pages. If you were to, say,
rpm -e perl.i386
would you expect it to remove the man pages or not. What would you expect
rpm -V perl
to report in either case. As far as I'm aware there is no such 'duplication' logic in the db. It would be cool if it could be made to work in general, however, I can think of some use cases that might rule this out. By using --force (or --replacefiles) you are effectively breaking the consistency of the install/upgrade/remove logic and yum should protect you from doing that by accident.
Stepping back a bit, why do you need both perl.i386 and perl.x86_64 packages? Which package 'owns' the /usr/bin/perl executable? None of my Centos 5 x86_64 systems have both and they have all gone through a recent perl upgrade, so I'm curious how you got both installed in the first place. Is there some dependency that pulled in the i386 package?
Kal _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 16/06/10 08:47, Gary Greene wrote:
On 6/15/10 3:26 PM, "Kahlil Hodgson" kahlil.hodgson@dealmax.com.au wrote:
Yes, this is frustrating. I've encountered it a number of times while packaging perl modules that override those in the core (e.g. Test::More). Sorry, but I've never found a really good solution beyond --force or --replacefiles.
This is the EXACT reason I use site_perl instead of vendor_perl prefixes for Perl modules that are not packaged by upstream for the internal repo we have here.
Yeah, I do the same, but it doesn't help with the man pages 'cause they get installed under /usr/share/man.
Building with, say, INSTALLMAN3DIR=none gets around it, but you can get a situation where man returns the documentation for the older module whereas perldoc returns the documentation for the module that is actually used. This may confuse some members of your development team :-(
K
On 06/15/2010 03:26 PM, Kahlil Hodgson wrote:
On 06/16/2010 06:10 AM, m.roth@5-cent.us wrote:
I'm trying to do an update to some servers... and they have both i386 and x86_64 perl. The latter won't update, because the idiotic *man pages* are dups. Is there *any* way, short of using rpm directly with a --force, to get yum to ignore the dups and do the update?
The only answer I've come up that works reliably is rebuilding at least one of the conflicting rpms with the man page generation suppressed.
Add: INSTALLDIRS=site INSTALLMAN1DIR=none INSTALLMAN3DIR=none
to the line of the spec file with the 'Makefile.PL' entry.
On 06/15/2010 03:52 PM, Benjamin Franz wrote:
On 06/15/2010 03:26 PM, Kahlil Hodgson wrote:
On 06/16/2010 06:10 AM, m.roth@5-cent.us wrote:
I'm trying to do an update to some servers... and they have both i386 and x86_64 perl. The latter won't update, because the idiotic *man pages* are dups. Is there *any* way, short of using rpm directly with a --force, to get yum to ignore the dups and do the update?
The only answer I've come up that works reliably is rebuilding at least one of the conflicting rpms with the man page generation suppressed.
Add: INSTALLDIRS=site INSTALLMAN1DIR=none INSTALLMAN3DIR=none
to the line of the spec file with the 'Makefile.PL' entry.
I realized after I sent that that it wasn't clear how to do it. The relevant line of the spec file will look something like this after editing:
%{__perl} Makefile.PL INSTALLDIRS=site INSTALLMAN1DIR=none INSTALLMAN3DIR=none `%{__perl} -MExtUtils::MakeMaker -e ' print qq|PREFIX=%{buildroot}%{_prefix}| if $ExtUtils::MakeMaker::VERSION =~ /5.9[1-6]|6.0[0-5]/ '`
Hi,
A bit of history is in order here: http://www.karan.org/blog/index.php/2010/06/17/why-is-there-a-perl-i386-in-m...
On 15/06/2010 21:10, m.roth@5-cent.us wrote:
I'm trying to do an update to some servers... and they have both i386 and x86_64 perl. The latter won't update, because the idiotic *man pages* are dups. Is there *any* way, short of using rpm directly with a --force, to get yum to ignore the dups and do the update?
I dont think that was the issue at all :)
And why does *anyone* make it so that a dup manpage is a reason to fail (and don't tell me they do it generically for any of the packages in the .rpm...)?
Its an artifact from the idea of multilib and its implementation in rpm, docs that md5 match between builds archs' of the same package are silently ignored. The other way to look at this is that two builds, for the same source will produce identical outputs if built under the same conditions ( makefiles, arch, buuild roots, dep chains, machine conditions etc ). When you extend that over multiple arch's, the docs are the only thing you need to be concerned about, since the binaries you get will depend on what and how the multilib policy is implemented on the machine. If you find there are conflicts in package-vers-release.arch where arch is the only variant - file a bug report; something in the buildsystem isn't doing its job right.
so, in summary : the problem you were seeing was not caused by a dupe manpage, it was caused by a dupe manpage from different versions of perl ( had the version been the same, and the md5's for the doc's been the same, they would not cause a conflict ).
There are different ways to handle this situation, but to be honest, I dont see much fault with the way things are right now with rpm multilib policy. it works.
- KB
Karanbir Singh wrote:
Hi,
A bit of history is in order here: http://www.karan.org/blog/index.php/2010/06/17/why-is-there-a-perl-i386-in-m...
On 15/06/2010 21:10, m.roth@5-cent.us wrote:
I'm trying to do an update to some servers... and they have both i386 and x86_64 perl. The latter won't update, because the idiotic *man pages* are dups. Is there *any* way, short of using rpm directly with a --force, to get yum to ignore the dups and do the update?
I dont think that was the issue at all :)
And why does *anyone* make it so that a dup manpage is a reason to fail (and don't tell me they do it generically for any of the packages in the .rpm...)?
Its an artifact from the idea of multilib and its implementation in rpm, docs that md5 match between builds archs' of the same package are silently ignored. The other way to look at this is that two builds, for the same source will produce identical outputs if built under the same conditions ( makefiles, arch, buuild roots, dep chains, machine conditions etc ). When you extend that over multiple arch's, the docs are the only thing you need to be concerned about, since the binaries you get will depend on what and how the multilib policy is implemented on the machine. If you find there are conflicts in package-vers-release.arch where arch is the only variant - file a bug report; something in the buildsystem isn't doing its job right.
so, in summary : the problem you were seeing was not caused by a dupe manpage, it was caused by a dupe manpage from different versions of perl ( had the version been the same, and the md5's for the doc's been the same, they would not cause a conflict ).
There are different ways to handle this situation, but to be honest, I dont see much fault with the way things are right now with rpm multilib policy. it works.
In this particular instance, is removing perl.i386 the right thing to do? Are there any common situations where it would be used on an x86_64 system?
On 17/06/2010 13:36, Les Mikesell wrote:
In this particular instance, is removing perl.i386 the right thing to do? Are there any common situations where it would be used on an x86_64 system?
Removing perl.i386 is the way to go here. I don't personally know of any situations where perl.i386 might have been required. Most people who are building perl modules should be linking with and against the perl.x86_64 anyway ( even when doing builds against native libraries ).
There are some vendors who still hand out binaries that need perl.i386; but in those cases, perl.i386 can be installed by name.
- KB
-
Benjamin Franz -
Gary Greene -
Kahlil Hodgson -
Karanbir Singh -
Les Mikesell -
m.roth＠5-cent.us