Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1517249 - perl-homedir is incompatible with rpmbuild -ba perl-*.spec
Summary: perl-homedir is incompatible with rpmbuild -ba perl-*.spec
Alias: None
Product: Fedora
Classification: Fedora
Component: perl-local-lib
Version: 26
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jitka Plesnikova
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-24 11:36 UTC by Mirosław Zalewski
Modified: 2017-11-24 11:49 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-11-24 11:49:13 UTC

Attachments (Terms of Use)

Description Mirosław Zalewski 2017-11-24 11:36:29 UTC
When perl-homedir is installed and enabled, `rpmbuild -ba` will fail for majority (all?) of perl packages. The reason is that perl build will put files in different locations than when RPM expects them (see below for all the details).

That was found on one of machines that sanity-checks RPM packages (rebuilds them and tries to install them). After perl-homedir was installed, subsequent checks for other perl package failed. In this particular case perl-homedir could be removed (or disabled for system user doing rebuilds), but I don't think that users should have to decide between perl-homedir and rpmbuild working as expected.

The root cause is INSTALL_BASE set to ~/perl5 in Makefile generated by perl. It comes from $PERL_MB_OPT and/or $PERL_MM_OPT environmental variables set by perl-homedir. Maybe perl RPM macro could filter/unset these variables on one of early setup stages?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Ensure that you have environment for building RPM packages (install rpmdevtools and rpm-build, run rpmdev-setuptree) and that perl-homedir package is installed and enabled (spawn new shell after installation)
2. Pick up noarch perl package for reproducing (e.g. perl-Getopt-Long)
3. Download source RPM of package (`dnf download --source perl-Getopt-Long`)
4. Install source RPM package (`rpm -i *.src.rpm`)
5. Install build-dependencies of source RPM package (`dnf builddep perl-Getopt-Long`)
6. Try to build package (`rpmbuild -ba ~/rpmbuild/SPECS/perl-Getopt-Long.spec`)

Actual results:
Build fails with message about missing files:
RPM build errors:
    File not found: /home/mzalewsk/rpmbuild/BUILDROOT/perl-Getopt-Long-2.40-3.fc26.x86_64/usr/share/perl5/vendor_perl/*
    File not found: /home/mzalewsk/rpmbuild/BUILDROOT/perl-Getopt-Long-2.40-3.fc26.x86_64/usr/share/man/man3/*

Expected results:
Build succeeds.

Additional info:
As shown by directory trees, perl-homedir causes perl build system to put files in home directory of user even inside build root:

tree -d ~/rpmbuild/BUILDROOT/perl-Getopt-Long-2.40-3.fc26.x86_64/
├── home
│   └── mzalewsk
│       └── perl5
│           ├── lib
│           │   └── perl5
│           │       ├── Getopt
│           │       └── x86_64-linux-thread-multi
│           │           └── auto
│           │               └── Getopt
│           │                   └── Long
│           └── man
│               └── man3
└── usr
    └── share
        └── doc
            └── perl-Getopt-Long
                └── examples

Directory tree without perl-homedir, for comparison:
└── usr
    ├── lib64
    │   └── perl5
    │       └── vendor_perl
    │           └── auto
    │               └── Getopt
    │                   └── Long
    └── share
        ├── doc
        │   └── perl-Getopt-Long
        │       └── examples
        ├── man
        │   └── man3
        └── perl5
            └── vendor_perl
                └── Getopt

%{perl_vendorlib} and %{_mandir} RPM macros support only second directory structure (and rightfully so), which causes them to resolve to non-existing paths if first tree was created.

Comment 2 Petr Pisar 2017-11-24 11:49:13 UTC
And it also adds a directory into PATH. Defining pristine environment is a job for rpm-build tool or more specifically for mock tool. Unsetting random variables in every spec file does not make sense and does not scale.

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