[users] Fixing up the Perl RPMs in the extras repo

[Dave Miller]

There's a bunch of perl modules in the extras repo that are there
because they are packaging newer versions of stuff that's included in
core Perl in RHEL. However, they're using the default install paths,
which causes most of them to not install without --force because of
conflicts with the core perl package already on the system.

I found a way to work around this:

Using this line to invoke Makefile.PL from the spec file:
(this is for RHEL5 - fix the perl version for RHEL6 of course)

%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl

I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally. And after all, this is the extras repo,
so you're intentionally trying to override core RHEL stuff by installing
from there anyway, right?

I'd recommend the majority of the Perl module packages in the extras
repo (especially the ones that are updating modules that are included in
RHEL's core perl package) be rebuilt with that line modified as such in
the spec file, so they can be installed without conflicts.

[Dave Miller]

Post by Dave Miller
There's a bunch of perl modules in the extras repo that are there
because they are packaging newer versions of stuff that's included in
core Perl in RHEL. However, they're using the default install paths,
which causes most of them to not install without --force because of
conflicts with the core perl package already on the system.

perl-Test-Harness is one of these, and it's NOT in the extras repo. It
probably should be. (it conflicts with perl on RHEL5)

[Pavel Kankovsky]

Post by Dave Miller
%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl
I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally.

Are there any conflicts involving files other than manpages?

Manpages could be installed in the standard directory (/usr/share/man)
if you changed their suffix. Unfortunately, the result is not quite
deterministic because it depends on the ordering of filenames
in a directory (man appears to always pick the last matching file).

Another solution would be to create (perhaps by way of a dedicated special
package the other packages would depend on) new manpage sections (e.g.
3rfx) and insert them into MANSECT in /etc/man.config before the standard
sections.

I am not sure whether it would be less or more controversial than
installing packaged files in /usr/local.

[Dave Miller]

Post by Pavel Kankovsky

Post by Dave Miller
%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl
I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally.

Are there any conflicts involving files other than manpages?

Yes. Several modules install shortcut binaries that normally go in
/usr/bin.

[Dave Miller]

Post by Pavel Kankovsky

Post by Dave Miller
%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl
I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally.

Are there any conflicts involving files other than manpages?

Yes. Several modules install shortcut binaries that normally go in
/usr/bin.

[Dave Miller]

Post by Pavel Kankovsky

Post by Dave Miller
%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl
I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally.

Are there any conflicts involving files other than manpages?

Yes. Several modules install shortcut binaries that normally go in
/usr/bin.

[Dave Miller]

Post by Pavel Kankovsky

Post by Dave Miller
%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl
I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally.

Are there any conflicts involving files other than manpages?

Yes. Several modules install shortcut binaries that normally go in
/usr/bin.

[Dave Miller]

Post by Pavel Kankovsky

Post by Dave Miller
%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl
I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally.

Are there any conflicts involving files other than manpages?

Yes. Several modules install shortcut binaries that normally go in
/usr/bin.

[Dave Miller]

There's a bunch of perl modules in the extras repo that are there
because they are packaging newer versions of stuff that's included in
core Perl in RHEL. However, they're using the default install paths,
which causes most of them to not install without --force because of
conflicts with the core perl package already on the system.

I found a way to work around this:

Using this line to invoke Makefile.PL from the spec file:
(this is for RHEL5 - fix the perl version for RHEL6 of course)

%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl

I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally. And after all, this is the extras repo,
so you're intentionally trying to override core RHEL stuff by installing
from there anyway, right?

I'd recommend the majority of the Perl module packages in the extras
repo (especially the ones that are updating modules that are included in
RHEL's core perl package) be rebuilt with that line modified as such in
the spec file, so they can be installed without conflicts.

[Dave Miller]

Post by Dave Miller
There's a bunch of perl modules in the extras repo that are there
because they are packaging newer versions of stuff that's included in
core Perl in RHEL. However, they're using the default install paths,
which causes most of them to not install without --force because of
conflicts with the core perl package already on the system.

perl-Test-Harness is one of these, and it's NOT in the extras repo. It
probably should be. (it conflicts with perl on RHEL5)

[Pavel Kankovsky]

Post by Dave Miller
%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl
I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally.

Are there any conflicts involving files other than manpages?

Manpages could be installed in the standard directory (/usr/share/man)
if you changed their suffix. Unfortunately, the result is not quite
deterministic because it depends on the ordering of filenames
in a directory (man appears to always pick the last matching file).

Another solution would be to create (perhaps by way of a dedicated special
package the other packages would depend on) new manpage sections (e.g.
3rfx) and insert them into MANSECT in /etc/man.config before the standard
sections.

I am not sure whether it would be less or more controversial than
installing packaged files in /usr/local.

[Dave Miller]

There's a bunch of perl modules in the extras repo that are there
because they are packaging newer versions of stuff that's included in
core Perl in RHEL. However, they're using the default install paths,
which causes most of them to not install without --force because of
conflicts with the core perl package already on the system.

I found a way to work around this:

Using this line to invoke Makefile.PL from the spec file:
(this is for RHEL5 - fix the perl version for RHEL6 of course)

%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl

I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally. And after all, this is the extras repo,
so you're intentionally trying to override core RHEL stuff by installing
from there anyway, right?

I'd recommend the majority of the Perl module packages in the extras
repo (especially the ones that are updating modules that are included in
RHEL's core perl package) be rebuilt with that line modified as such in
the spec file, so they can be installed without conflicts.

[Dave Miller]

Post by Dave Miller
There's a bunch of perl modules in the extras repo that are there
because they are packaging newer versions of stuff that's included in
core Perl in RHEL. However, they're using the default install paths,
which causes most of them to not install without --force because of
conflicts with the core perl package already on the system.

perl-Test-Harness is one of these, and it's NOT in the extras repo. It
probably should be. (it conflicts with perl on RHEL5)

[Pavel Kankovsky]

Post by Dave Miller
%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl
I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally.

Are there any conflicts involving files other than manpages?

Manpages could be installed in the standard directory (/usr/share/man)
if you changed their suffix. Unfortunately, the result is not quite
deterministic because it depends on the ordering of filenames
in a directory (man appears to always pick the last matching file).

Another solution would be to create (perhaps by way of a dedicated special
package the other packages would depend on) new manpage sections (e.g.
3rfx) and insert them into MANSECT in /etc/man.config before the standard
sections.

I am not sure whether it would be less or more controversial than
installing packaged files in /usr/local.

[Dave Miller]

There's a bunch of perl modules in the extras repo that are there
because they are packaging newer versions of stuff that's included in
core Perl in RHEL. However, they're using the default install paths,
which causes most of them to not install without --force because of
conflicts with the core perl package already on the system.

I found a way to work around this:

Using this line to invoke Makefile.PL from the spec file:
(this is for RHEL5 - fix the perl version for RHEL6 of course)

%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl

I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally. And after all, this is the extras repo,
so you're intentionally trying to override core RHEL stuff by installing
from there anyway, right?

I'd recommend the majority of the Perl module packages in the extras
repo (especially the ones that are updating modules that are included in
RHEL's core perl package) be rebuilt with that line modified as such in
the spec file, so they can be installed without conflicts.

[Dave Miller]

Post by Dave Miller
There's a bunch of perl modules in the extras repo that are there
because they are packaging newer versions of stuff that's included in
core Perl in RHEL. However, they're using the default install paths,
which causes most of them to not install without --force because of
conflicts with the core perl package already on the system.

perl-Test-Harness is one of these, and it's NOT in the extras repo. It
probably should be. (it conflicts with perl on RHEL5)

[Pavel Kankovsky]

Post by Dave Miller
%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl
I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally.

Are there any conflicts involving files other than manpages?

Manpages could be installed in the standard directory (/usr/share/man)
if you changed their suffix. Unfortunately, the result is not quite
deterministic because it depends on the ordering of filenames
in a directory (man appears to always pick the last matching file).

Another solution would be to create (perhaps by way of a dedicated special
package the other packages would depend on) new manpage sections (e.g.
3rfx) and insert them into MANSECT in /etc/man.config before the standard
sections.

I am not sure whether it would be less or more controversial than
installing packaged files in /usr/local.

[Dave Miller]

There's a bunch of perl modules in the extras repo that are there
because they are packaging newer versions of stuff that's included in
core Perl in RHEL. However, they're using the default install paths,
which causes most of them to not install without --force because of
conflicts with the core perl package already on the system.

I found a way to work around this:

Using this line to invoke Makefile.PL from the spec file:
(this is for RHEL5 - fix the perl version for RHEL6 of course)

%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl

I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally. And after all, this is the extras repo,
so you're intentionally trying to override core RHEL stuff by installing
from there anyway, right?

I'd recommend the majority of the Perl module packages in the extras
repo (especially the ones that are updating modules that are included in
RHEL's core perl package) be rebuilt with that line modified as such in
the spec file, so they can be installed without conflicts.

[Dave Miller]

Post by Dave Miller
There's a bunch of perl modules in the extras repo that are there
because they are packaging newer versions of stuff that's included in
core Perl in RHEL. However, they're using the default install paths,
which causes most of them to not install without --force because of
conflicts with the core perl package already on the system.

perl-Test-Harness is one of these, and it's NOT in the extras repo. It
probably should be. (it conflicts with perl on RHEL5)

[Pavel Kankovsky]

Post by Dave Miller
%{__perl} Makefile.PL LIB="/usr/lib/perl5/vendor_perl/5.8.8"
INSTALLMAN1DIR="/usr/local/lib/man/man1"
INSTALLMAN3DIR="/usr/local/lib/man/man3" INSTALLBIN="/usr/local/bin"
INSTALLSCRIPT="/usr/local/bin" INSTALLDIRS=perl
I know putting stuff into /usr/local from an RPM is controversial, but
this way it lets it install stuff without conflicting with core
packages, and also puts the installed files first in your path, so you
can actually use them normally.

Are there any conflicts involving files other than manpages?

Manpages could be installed in the standard directory (/usr/share/man)
if you changed their suffix. Unfortunately, the result is not quite
deterministic because it depends on the ordering of filenames
in a directory (man appears to always pick the last matching file).

Another solution would be to create (perhaps by way of a dedicated special
package the other packages would depend on) new manpage sections (e.g.
3rfx) and insert them into MANSECT in /etc/man.config before the standard
sections.

I am not sure whether it would be less or more controversial than
installing packaged files in /usr/local.

[Pavel Kankovsky]

Post by Dave Miller

Post by Pavel Kankovsky
Are there any conflicts involving files other than manpages?

Yes. Several modules install shortcut binaries that normally go in
/usr/bin.

I know. Are any of them in conflict with files in the Perl RPM?
Hmm... I have found three conflicts (to my suprise I found them in
rpmforge proper rather than in rpmforge-extras):

/usr/bin/h2xs and /usr/bin/piconv in perl-Encode
/usr/bin/prove in perl-Test-Harness

RPM should support "diversions" a la dpkg-divert.

[Pavel Kankovsky]

Post by Dave Miller

Post by Pavel Kankovsky
Are there any conflicts involving files other than manpages?

Yes. Several modules install shortcut binaries that normally go in
/usr/bin.

I know. Are any of them in conflict with files in the Perl RPM?
Hmm... I have found three conflicts (to my suprise I found them in
rpmforge proper rather than in rpmforge-extras):

/usr/bin/h2xs and /usr/bin/piconv in perl-Encode
/usr/bin/prove in perl-Test-Harness

RPM should support "diversions" a la dpkg-divert.

[Pavel Kankovsky]

Post by Dave Miller

Post by Pavel Kankovsky
Are there any conflicts involving files other than manpages?

Yes. Several modules install shortcut binaries that normally go in
/usr/bin.

I know. Are any of them in conflict with files in the Perl RPM?
Hmm... I have found three conflicts (to my suprise I found them in
rpmforge proper rather than in rpmforge-extras):

/usr/bin/h2xs and /usr/bin/piconv in perl-Encode
/usr/bin/prove in perl-Test-Harness

RPM should support "diversions" a la dpkg-divert.

[Pavel Kankovsky]

Post by Dave Miller

Post by Pavel Kankovsky
Are there any conflicts involving files other than manpages?

Yes. Several modules install shortcut binaries that normally go in
/usr/bin.

I know. Are any of them in conflict with files in the Perl RPM?
Hmm... I have found three conflicts (to my suprise I found them in
rpmforge proper rather than in rpmforge-extras):

/usr/bin/h2xs and /usr/bin/piconv in perl-Encode
/usr/bin/prove in perl-Test-Harness

RPM should support "diversions" a la dpkg-divert.

[Pavel Kankovsky]

Post by Dave Miller

Post by Pavel Kankovsky
Are there any conflicts involving files other than manpages?

Yes. Several modules install shortcut binaries that normally go in
/usr/bin.

I know. Are any of them in conflict with files in the Perl RPM?
Hmm... I have found three conflicts (to my suprise I found them in
rpmforge proper rather than in rpmforge-extras):

/usr/bin/h2xs and /usr/bin/piconv in perl-Encode
/usr/bin/prove in perl-Test-Harness

RPM should support "diversions" a la dpkg-divert.