On Tue, Nov 12, 2013 at 11:20 AM, Abdó Roig-Maranges <abdo.r...@gmail.com> wrote: > > Hi > > mich...@orlitzky.com writes: > >> * Bundling libraries are terrible for security. I should be able to >> open a PNG in code that I myself wrote, without worrying about a >> buffer overflow. My distro patches these holes immediately. Sage >> doesn't, there's just not enough manpower. >> >> * It's wasted thousands of hours of developer time. Look at the >> ChangeLog for a major release -- how many of the tickets are math? >> How many are a result of trying to bootstrap the universe?
I think many (most) of these issues are inherent to updating dependencies and would have occurred whether or not Sage is shipping the sources themselves. >> * It doesn't work. At the boundary between stuff-we-build and stuff- >> the-system-provides, things break. Sage uses the dvipng built >> against my system's gd, but runs it against the one bundled with >> sage. *crash* Guess I can't plot anything today. >> >> * Distributions won't touch it. Linux users should be our bread and >> butter, but they can't install it. I should be able to tell people >> "just type 'yum install sage'", but instead, I have to teach them >> how to initiate a big bang the result of which, after millions of >> seconds, might look like sage. Then they run into the aforementioned >> problems anyway. > > And some more points: > > * If sage started to use what is available on the system, instead of > duplicating effort, probably more linux distros would start packaging it. > > * Depending on things instead of bundling them is the standard practice. I'd > even say that the "batteries included" policy is kind of arrogant. Sage can > pull this off only because it is virtually the only software package doing > it. If every software depending on git, or zlib or python shipped their own > version, things would get unbearable pretty fast. In this sense sage is not > being a good neighbour in the system. > > * System git and sage git share resources, like the main config file at > ~/.gitconfig. What if it becomes incompatible between system and sage's git > versions? The same goes for any other lib or standard tool sage > uses. Embedding the tools within sage looks like shifting away the > "different > versions problem" from developer hands to the user. > > > I realize sage might have kind of unique needs to patch specific software, and > might have hard dependencies on specific versions of certain scientific > libraries. But I believe this policy of bundling everything should not be the > rule, but an exception. Even more so for stable standard stuff like git, zlib, > etc. > > If sage finds a bug to a package, it should first try fixing it upstream, then > try to work-around it, and as a last resort, bundle a patched version. That is > the usual way open-source communities operate. > > An other issue is having a "batteries included" tarball around. That may be > nice > for some, I understand that, but it shouldn't be the only option. > > Also, I think sage gets the focus wrong on this issue. Sage should aim at > making > the code base as adaptable as possible to different environments, and software > versions, instead of trying to carefully control the environment. In the long > run that should ease sage's own development! for instance when upgrading > bundled > python. It is a matter of being aware of what is backwards compatible and what > isn't when writing code. For instance, always use '--porcelain' versions of > git > commands, etc. Writing code that works against, for example, multiple versions of Python takes extra care, as does testing it. Expand this to many different libraries and one has a full cross product of possible failure modes. Couple that with the (like it or not) common pattern of learning correctness (or to code at all) by "what works on my machine" and there's value to having a standard environment. Transferring that to "works on your machine too" *is* harder the more underlying libraries can vary, and also negatively impacts reproducibility (which has practical applications for development and academic value). It's trading one set of issues for another. > As I said, it may not be possible to be that adaptable for some libs (so then > bundle them!). But for a non-negligible amount of software sage depends on, > I'm > certain it is possible and mostly painless in the long run to be more > adaptable. Autotools is a mature and portable piece of software which aims to > do > just that, to adapt the source tree to the particularities of the build > environment before building. A proof that this can be achieved is that > virtually > every single open source software except sage manages to do it! Sage is an > awesome piece of software, but is not that special to be different from > everybody else in that respect. I think Sage is unique in the number of dependencies that are not (or likely never will be) maintained by professional developers and packaged in mainstream distributions (e.g. cliquer, ecm, flint, genus2reduction, gfx2, gfan, givaro, iml, lcalc, fpll, m4ri, ...) I agree that there are also a huge number of libraries that are almost silly to build ourselves (zlib, sqlite, patch, ...) but at least shipping them has value over making a hard dependency. > What seems kind of scary is the amount of work needed to do that, but it seems > Felix has already walked a long way in that direction, isn't it? To clarify my position, I am fully supportive of such efforts (e.g. lmonade). Once we move over to git, this can even be a branch with easy sharing of code back and forth (compared to the way it is now). I think the two modes can coexist, and am hopeful that Sage can eventually move more and more this direction. Unless we require all dependencies to be upstream (that'll never happen) Sage will have to deal with packaging itself (hopefully via a standard package manager that, well, it will probably have to ship). Also, I am convinced we need an incremental system rather than trying to replace the whole system at once. Most importantly, this should not be a blocker for moving to git. - Robert -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
