Fedora scientific packaging
lists at petetravis.com
Sat Nov 22 09:04:49 UTC 2014
On 11/21/2014 11:22 PM, M. Edward (Ed) Borasky wrote:
> I think the Fedora policy requires more of a commitment from
> maintainers than I can offer. In any event, I know RStudio Server can
> be built from source on Fedora and that it works but it needs a lot of
> detailed attention to turn it into something that will make it into a
> release. It has a few dependencies - gwt, for one - that aren't in
> Fedora so their source needs to be packaged in the source RPM.
> There's also the question of upstream - they have a build process that
> makes usable binaries for openSUSE and Fedora but only support the
> server on Debian, Ubuntu, RHEL and CentOS. I did get them to fix some
> issues when their run-time dependencies messed up a Fedora R upgrade,
> but I don't know if they'd actively participate in a distro packaging
> effort. They'd need to be asked.
> All that said, this is a good time to start such a project, since
> Fedora 21 is about two weeks away from release. I have a COPR project
> opened but haven't put anything in it yet -
> On Fri, Nov 21, 2014 at 8:38 PM, Suchakra <suchakra at fedoraproject.org
> <mailto:suchakra at fedoraproject.org>> wrote:
> > What do you say, Ed? If I get the package review done, will you
> help with
> > bugs and maintenance?
> > --Pete
> I am using RStudio actively on Fedora using the rpm they provide.
> Though it works just about satisfactorily for me standalone, it would
> really be nice to have it in our repos. I can help in testing/bugs and
> occasional maintenance.
> devel mailing list
> devel at lists.fedoraproject.org <mailto:devel at lists.fedoraproject.org>
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Twitter: http://twitter.com/znmeb; Computational Journalism on a Stick
> Remember, if you're traveling to Bactria, Hump Day is Tuesday and
I just glanced at their github repo.. wow.
https://github.com/rstudio/rstudio/releases - it looks like they are
tagging a 'release' every time they touch the code. There's also a lot
of bundling; probably not an insurmountable amount, but it won't be an
easy one to package.
As for upstream suppport... well, the bundling is indicative of how
they'd probably feel about keeping up with our dependency churn. It
isn't uncommon for upstreams to not actively participate in the
packaging process, but if they're taking the stance where 'we only
support the latest release (ha!) with these specific versions of deps'
it would be a nightmare. Detailed attention is right :)
Anyway, I'll keep an eye on this thread and if there's enough interest,
I'll happily participate in the packaging. Still definitely more than I
want to take on alone - but it does look like an interesting challenge.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel