On Thu, 23 May 2013 14:02:34 +0200
Jan Zelený <jzeleny(a)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