Hi Bertrand, We applaud you for taking on this work, however you should know that we plan on doing it as well in due time. The biggest issue you will face in attempting to package RStudio is the fragility of certain dependencies (mostly QtWebKit). i.e. the product breaks in subtle ways when moving from one minor Qt release to the next. That's the main reason to date that we have chosen to pin versions of various dependencies. Another reason is that often we need the *very latest* (or even a patched) version of large complex software like Boost, Qt, or GWT to work correctly. We are an *extremely* small team and having the software work against a large matrix of these dependencies is too much to keep up with right now.
There's a philosophical and practical issue in play here: many large/complex software projects choose embedded dependencies both as a way to achieve a sane test matrix and as a way of exercising required control over patches / bug fixes in dependencies. As you start to unroll this it gets harder and harder to keep up (i.e. you could package GWT but then it in turn has a bunch of embedded dependencies, you could package those as well but then you get further off of being able to track to the latest GWT release or even to GWT trunk). Net: it's really hard for a large product developed by a small team like RStudio to take all dependencies dynamically without either (a) Escalating the engineering and testing cost unacceptably; or (b) Making it so folks running RStudio on mainstream distros aren't stuck running much older versions of the product. As an example, we recently migrated from Qt 4.7 to Qt 5.4 to get dramatically improved UI performance. We found that we were unable to run against Qt 5.1, 5.2, and 5.3 for various reasons (some missing features, some difficult to track down bugs). We made the move to Qt 5.4 and can now support that on Ubuntu 12.04+. Had we not been using embedded dependencies though we actually couldn't even support Ubuntu 14.04 (since it includes Qt 5.2). It's not acceptable to most customers to run Debian testing just to use the latest version of RStudio. In fact, just moving to Qt 5 would have forced us to drop Ubuntu 12.04. This would have been a complete non-starter so we'd need the product to compile and run correctly against BOTH Qt 4 and Qt 5. Not impossible (QtCreator does it) but a large cost for a small team. The same thing will be playing out again with Qt 5.6 where we'll move to using QtWebEngine (Chromium). It's just too much for us to maintain two versions of the code (one that supports QtWebKit and one that supports QtWebEngine) and much, much better for customers to run against the faster Chromium engine. Again, I applaud your efforts but I think that you'll find you need to maintain your own branch of a heavily modified RStudio in order to sustainably keep it packaged for Debian. We'll ultimately take this work on ourselves once we feel that dependencies are sufficiently stable (likely after Qt 5.6 this winter). J.J. On Sun, Sep 27, 2015 at 7:57 AM, Tareef Kawaf <tar...@rstudio.com> wrote: > Hi Bertrand, > I am forwarding this along to our engineering team. For now > i...@rstudio.com might be the best way to communicate with us. > Will let you know what I find and how easy it would be to implement > Tareef > > On Sunday, September 27, 2015, Bertrand Marc <beberk...@gmail.com> wrote: > >> Dear Rstudio developpers, >> >> First of all, thank you for your great work on Rstudio. >> >> I am trying to package rstudio for Debian (so it would be accessible for >> all Debian/user easily). But to achieve this, I need to exclude every >> third party from the build process, and force Rstudio to use system >> libraries, jars and other external dependencies [1]. So far, I tweaked >> src/cpp/session/CMakeLists.txt [2], but this is only the beginning. I >> would need a way to keep your code and exclude third party code from >> /home/bbk/linux/rstudio/src/cpp/session/resources or in src/gwt for >> instance. And then I need to make sure Rstudio uses system dependencies. >> I think the best way to achieve this would be (an) option(s) to pass at >> configure time. >> >> Would you be kind enough to help me and point me to right direction ? It >> would be a great help ! >> >> Regards, >> Bertrand >> >> PS What is the preferred way to contact you ? Do you have some kind of >> bug tracker ? I could not find one on github. >> >> [1] >> https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_party_code >> [2] >> >> http://anonscm.debian.org/cgit/debian-science/packages/rstudio.git/commit/?id=adf3296b9c05757c56ac0f39b093a68a346b3afe >> >>
