On 23. 5. 2013 at 15:30:55, Stijn Hoop wrote:
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.
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