RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1038308 - perl-devel dependencies causing production upgrade nightmares (source of problem: #905482)
Summary: perl-devel dependencies causing production upgrade nightmares (source of prob...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: perl
Version: 6.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: perl-maint-list
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-04 21:16 UTC by Chris
Modified: 2017-08-15 10:57 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-05 07:42:31 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 905482 0 unspecified CLOSED perl's Config libs contains -lgdbm but it is not in perl-devel 2021-02-22 00:41:40 UTC

Internal Links: 905482

Description Chris 2013-12-04 21:16:39 UTC 
Description of problem:
Bug 905482 - perl's Config libs contains -lgdbm but it is not in perl-devel (https://bugzilla.redhat.com/show_bug.cgi?id=905482) opened a huge can of worms by requiring glibc-devel, db4-devel and gdbm-devel.  Now virtually anyone who's using the 'perl-devel' package is forced to install kernel headers (a dependency of glibc-devel) along with other packages they aren't necessarily using. It's not uncommon for a package to be compiled against other libraries to support them,  but for this reason alone it shouldn't be a dependency. 

If you install python-devel into your environment, you aren't additionally forced to install all of the dependencies it's compiled against.  Why should perl-devel be different?

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

How reproducible:
just install an earlier version of perl-devel to accommodate package requirements (like spamassassin has and amavisd-new).

run an update on your system and find out that it wants to now haul in glibc-devel, gdbm-devel, and db4-devel. Then glibc-devel in turn has a dependency of kernel-headers...  No one wants this on their production system.

Expected results:
I want to run yum update perl-devel and just update perl-devel. Dependencies are okay, but they shouldn't be included for the soul sake of a lazy developer who just couldn't have included them himself in the same yum command which is all #905482 turned out to be.

Additional info:
perl.spec (http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/perl-5.10.1-136.el6.src.rpm) line: 358

Please remove:
   Requires:       glibc-devel, gdbm-devel, db4-devel
Comment 1 Petr Pisar 2013-12-05 07:42:31 UTC 
perl-devel is for building Perl packages. The word package does not mean RPM package. It means Perl package as defined by CPAN. I.e. a source archive delivering possibly many Perl modules and a build script (Makefile.PL or Build.PL usually) to build and install them.

Perl modules are common to be written in C. Those are so called XS modules. To build those modules, perl headers are needed. Those perl headers include glibc headers, hence perl-devel depends on glibc-devel.

Therefore it's correct to pull glibc-devel in by perl-devel.
Comment 2 Tomasz Kłoczko 2017-08-15 10:34:18 UTC 
(In reply to Petr Pisar from comment #1)
> perl-devel is for building Perl packages. The word package does not mean RPM
> package. It means Perl package as defined by CPAN. I.e. a source archive
> delivering possibly many Perl modules and a build script (Makefile.PL or
> Build.PL usually) to build and install them.

So please name these perl modules on CPAN which are not packaged in Fedora and are uses libdb or libgdbm.
I don't see even single such package and this is why I've proposed *only partial solution* by remove only two packages from devel dependencies which will not hurt ANY build package ..

Even if such packages exist and if they will be not detecting libdb or libgdbm and relaying that -gdbm or -ldb will be delivered by $Config{perrlib} or $Config{libs} *build of such modules will fail* now even if gdbm-devel or libdb-devel will be installed.
All because none $Config variables are offering those libraries!!!

Do you see this now?

If you will find such modules please let me know I promise I'll try to fix those modules :)
However I'm 100% sure that my help will be not necessary :P

> Perl modules are common to be written in C. Those are so called XS modules.
> To build those modules, perl headers are needed. Those perl headers include
> glibc headers, hence perl-devel depends on glibc-devel.
> 
> Therefore it's correct to pull glibc-devel in by perl-devel.

Of course because it is rally hard to write anything which is not using glibc-devel. Most of the perl-devel C header files are using glibc headers and *only by this* glibc-devel should be in perl-devel Reguires list.
If you have impression that I'm suggesting do this it is only impression and it is not even correct impression.

What I'm suggesting is only remove -lc from all $Config variables.
But again such subject is not the scope of this ticket.

This ticket is ONLY about remove two Requires from generated perl-devel package and nothing more. I've added few other comments because you are mention things which are not correct according what linker is doing or what was done in 4 years ago affected perl module. By this you seems still you are thinking that adding four years ago to perl-devel additional static dependencies was correct.

No, despite that this fixed this module build it was not correct fix and now this fix even has been obsoleted by what changes in mean time in perl.
My change is only about mirror what perl-devel really offers or more precisely not offers to other perl modules build procedures.
Do you see this now?

Petr .. please focus on the subject :(
Again: this ticket is ONLY about remove gdbm-devel and libdb-devel dependencies which are added manually to devel subpackage.
Comment 3 Tomasz Kłoczko 2017-08-15 10:57:34 UTC 
Please ignore my last comment.
By mistake I've commented wrong ticket :)
Note You need to log in before you can comment on or make changes to this bug.