Petr P. has suggested that XML::LibXSLT should in fact use perllibs, not libs. I've filed a ticket against upstream now: https://rt.cpan.org/Ticket/Display.html?id=83028

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

perl-devel could run-depend gdbm-devel.

If we decides to run-requires gdbm-devel, we should run-require all providers of the libraries:

# perl -MConfig -e 'print $Config{libs}, qq{\n}'
-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc

I.e.: glibc-devel, gdbm-devel, db4-devel.

This fix broke our AWS EC2 AMIs as it introduced a bunch of extra -devel packages into minimal package set, https://bugzilla.redhat.com/show_bug.cgi?id=1017339

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1534.html

Applications like spamassassin, and amavisd-new have dependencies on perl-ExtUtils-ParseXS and perl-ExtUtils-MakeMaker to work.

ExtUtils-ParseXS and perl-ExtUtils-MakeMaker depend on perl-devel for a few of the tools provided in /usr/bin/* by the devel package and the Encode modules?

Anyway... now people who run a small mail server upgrading their perl libraries to accommodate the 'CVE-' security updates now have to haul in all of glib and compiling libraries which in turn pull in kernel headers too.

All because one person didn't like adding 3 more packages to their 'yum install' line?

I'd really like to request this be rolled back and the people who are installing the perl-devel library to build the same specific modules the original poster was building. Get rid of 'Requires: glibc-devel, gdbm-devel, db4-devel' in it's entirety.

If you just install gdbm-devel, it doesn't in turn grab glibc-devel, so why should perl-devel do this? Try installing python-devel,  You'll see you don't haul in any of these glibc-devel libraries and kernel headers either. You'll JUST pull in the package alone allowing you to work with it as you need to.

The soul purpose of the 'perl-devel' package should not depend on these other packages at all. Heck that's what configure.ac scripts are for. If you're a developer building with required packages, you specify in your documentation, your prepare/configure scripts. Your configure script can check for them and fail your install if they're missing... Tell your user their missing packages like everyone else does. Heck, make it even easier on them, do it the RedHat way and package it through RPMs. Then you can put: 'Requires: glibc-devel  gdbm-devel  db4-devel' in your own spec file but it should not be in 'perl-devel' at all.


Chris

(In reply to Chris from comment #17)
> Applications like spamassassin, and amavisd-new have dependencies on
> perl-ExtUtils-ParseXS and perl-ExtUtils-MakeMaker to work.

Why have those applications a run-dependency on something which judging by its name should primarily be used for build?

> ExtUtils-ParseXS and perl-ExtUtils-MakeMaker depend on perl-devel for a few
> of the tools provided in /usr/bin/* by the devel package and the Encode

That sounds expected -- they are build tools/modules, unlike spamassassin and amavisd-new.

> Anyway... now people who run a small mail server upgrading their perl
> libraries to accommodate the 'CVE-' security updates now have to haul in all
> of glib and compiling libraries which in turn pull in kernel headers too.
> 
> All because one person didn't like adding 3 more packages to their 'yum
> install' line?

The reason why the one person (me) filed this bugzilla was not because they were lazy but because there was an inconsistency between what packaged perl ships in Config and what was in perl and perl-devel packages. Please see comment 0, Expected results:

   The make should pass. Either the -lgdbm should not be in $Config{libs},
   or perl-devel should require gdbm-devel.

Please note that the use case is about building another module, for which I assume the dependency on perl-devel is justified.

Please also note that it was this inconsistency which prevented some operation (installation of the package) in contexts when running that 'yum install' line is not easy or outright not possible, like OpenShift.

> I'd really like to request this be rolled back and the people who are
> installing the perl-devel library to build the same specific modules the
> original poster was building. Get rid of 'Requires: glibc-devel, gdbm-devel,
> db4-devel' in it's entirety.
> 
> If you just install gdbm-devel, it doesn't in turn grab glibc-devel, so why
> should perl-devel do this?

Because 

  # perl -MConfig -le 'print $Config{libs}'
  -lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc

> Try installing python-devel,  You'll see you
> don't haul in any of these glibc-devel libraries and kernel headers either.
> You'll JUST pull in the package alone allowing you to work with it as you
> need to.

Work with what? The purpose to X-devel packages seems to be to build libraries/extensions on top of/using X. If it works for python, fine. But it does not seem to work for perl.

> The soul purpose of the 'perl-devel' package should not depend on these
> other packages at all. Heck that's what configure.ac scripts are for. If
> you're a developer building with required packages, you specify in your
> documentation, your prepare/configure scripts. Your configure script can
> check for them and fail your install if they're missing... Tell your user
> their missing packages like everyone else does. Heck, make it even easier on
> them, do it the RedHat way and package it through RPMs. Then you can put:
> 'Requires: glibc-devel  gdbm-devel  db4-devel' in your own spec file but it
> should not be in 'perl-devel' at all.

True. As long as it's not in %Config either.

(In reply to Chris from comment #17)
> 
> I'd really like to request this be rolled back and the people who are

Please work with your Red Hat support contact to have your request tracked by Red Hat support and engineering -- this bugzilla is now closed since the errata went out and if any other change is to be made (like revert), it needs to be tracked as completely new issue from start to end.

Thank you, Jan

'make' is a build tool as well and it doesn't haul in the glibc-devel modules because this tool can be used for other things as well.

You can also install the gdbm-devel and db4-devel without hauling in all of the glibc-devel and it's dependencies as well.

Perhaps the solution is to separate the dependencies within perl-devel (required by perl-ExtUtils-ParseXS and perl-ExtUtils-MakeMaker) into a different module?

Anyway, I'm not going to argue with a RedHat representative of the perl library.  If you strongly feel this was the right decision then by all means keep it.  I'll just recompile it with those lines missing for myself. Thank you for justifying your reasoning more.

In addition to that, I also am sorry for my rant above.  It was a heat of the moment thing when I preformed a simple 'yum update' on my system and all these development modules wanted to be installed too.  I traced it back to this package and got frustrated. I should have waited a day and made a more mature post instead of what I wrote.