Software Management call for RFEs

[Stijn Hoop]

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.

> > 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