Software Management call for RFEs

[Nico Kadel-Garcia]

On Thu, May 23, 2013 at 4:53 AM, Stijn Hoop <stijn at sandcat.nl> wrote:
> Hi,
>
> I would like better integration with domain-specific package managers.
> By which I mean npm (for node.js), gem (for ruby), pip (for python),
> cpan (for perl), pecl/pear (for PHP), CRAN (for R), CTAN (for TeX), and
> many more I'm sure.

You left out "maven". And first off, those are not "yum" behaviors,
they're "rpm" or "rpmbuild" behaviors. .

Second, the second you start letting yum and RPM grab modules
automatically from any of those third party repositories, you are in
dependency and compatibility hell. To take an example, look at the
perl-HTML-Mason package. It's been evolving reasonably quickly and
bopping back and forth between distinct authors with distinct styles,
so the dependency lists keep changing and updating to very recent
versions of other modules. As you bring in more Perl dependencies,
automatically, via local cpan builds, you lose track of which RPM you
built and installed in what fashion and can wind up with dependencies
based on the latest builds from CPAN that *break* your existing
codebase, or even wind up upgrading your version of perl. (Been there
with "cpan build", done that, had one hell of a time cleaning up the
mess!)

I've done a lot of work with CPAN -> RPM building, and it's painful
(That's why I keep updated versions of "cpan2rpm" and "cpanspec" up at
https://github.com/nkadel/)

> By integrating RPM with these package managers, I feel it would be
> possible to provide a consistent view of the system, as well as a
> consistent management interface for sysadmins as opposed to application
> developers. The latter I might expect to continue to use the domain
> specific package managers, simply because they add value to domain
> experts -- but for the common usecase "install this app on the server"
> it would be nice to use RPM only.

It's possible to have some tools to help with such building, but
that's a package creation issue, not a package management issue. The
same issues exist

> Another advantage that I see is that it saves Fedora packager manpower
> -- if the "translation" is good enough, it should be possible to work
> with upstream packages and simply automate the fedora rpm process as
> much as possible. Current examples are R2spec and the TeXLive package
> scripts.

TexLive is well defined. CPAN, rubygems, Maven, php/pear, etc.? Not so
much. Rubygems is particularly scary because the gems *do not publish
compilable source* for any well defined build environment, they rely
extensively on pre-built modules. Maven has the same "I publish
binaries, not buildable source code" problem.  CPAN is a nightmare:
the stylistic differences among the developers make consistent RPm
building a very, very manual process: TexLive is so well organized as
a monolithic, buildable source environment that it works well, I'll
admit, but but not the others.