On Thu, May 23, 2013 at 4:53 AM, Stijn Hoop <stijn@xxxxxxxxxx> 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
