Software Management call for RFEs

[Jan Zelený]

On 23. 5. 2013 at 15:30:55, Stijn Hoop wrote:
> On Thu, 23 May 2013 14:02:34 +0200
> 
> Jan Zelený <jzeleny at redhat.com> 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