On Thu, 23 May 2013 14:02:34 +0200 Jan Zelený <jzeleny@xxxxxxxxxx> wrote: > On 23. 5. 2013 at 10:53:10, Stijn Hoop wrote: > > 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. > > The problem is that some of these languages have fundamentally > different philosophy than Fedora and unfortunatelly it's not a > mix-and-match situation. That being said, there already are different > tools to create spec files from those upstream representations > (gem2spec, cpan2spec, ...) Yes, it is true that there sometimes is a different philosophy, but fundamentally is "in the eye of the beholder". If there are domain2spec tools available NOW, why would it not be possible technically? And if the non-technical philosophical differences are too big, maybe it is also a sign that Fedora needs to change the requirements? After all, an OS that does not help developers with development might not be a good environment to keep. > > 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. > > > > 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. > > You can't really do this because of all the Fedora packaging > policies. It might be feasible in some private repositories though. I disagree. Why are the domain2spec and TeXLive approaches in the repository then? I know that some domain2spec tools do need hand-editing, but that is a problem that can be worked on. Either by integrating more knowledge in the tools, or working with upstream on providing more metadata for the package. I do acknowledge that all of this will not be EASY. But then, I did not see that in your list of requirements. If it is really impossible, can you give an practical example why? (Sidenote: I really do appreciate the call for features and the considered feature page. Thank you for that!) Regards, --Stijn -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
