On 23. 5. 2013 at 15:30:55, Stijn Hoop wrote: > 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. I will give a simple example: Fedora - Ruby. Those are two completely different worlds that will probably never synchronize their philosophies. And you can't say which one should take a step back because they both have valid points in their philosophies. > > > 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. Well, technically it might be possible. It's just that I have strong doubts that the domain2spec tools can be improved to the degree where they can handle *any* domain-based package and produce rpm package that can be accepted to Fedora. Again, with private repositories, this won't be a concern and we can happily go for it, as there is no such thing as policy there ;-) > (Sidenote: I really do appreciate the call for features and the > considered feature page. Thank you for that!) Don't thank me yet, we still don't have neither the roadmap nor the list of accepted RFEs ;-) Thanks Jan -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
