Hi Georg, On Jan 24, 1:24 am, "Georg S. Weber" <georgswe...@googlemail.com> wrote: > Hi Dmitrii, > > > > > > > OK, I oversimplified. > > > As far as a practical step towards having more flexibility: > > Presently Sage does not have any mechanism allowing for "virtual" > > packages (I am stealing from Debian/Fink here) > > that would allow for using the already installed, somewhere on the > > system, non-Sage part of a Sage spkg. > > It would check if what's already installed satisfies the > > prerequisites, > > and if not, (sage -install, say) would pull a replacing "full" spkg > > from a Sage repository. > > Of course in some cases the pre-requisites check is quite tricky, but > > there are trivial cases, like bzip and mercurial, too... > > > How hard would it be to have such a thing? > > See below ... > > > > > > > > Sage has a cross-platform build system and environment. One question > > > that is related to the discussion in this thread is what the situation > > > is with other cross-platform build environments. Of course I know > > > about Debian/Fink/Cygwin/etc., which are specific to different > > > operating systems. Does anybody know of *any* good cross-platform > > > build environments besides Sage? Python + > > > (distutils+distribute+whatever) is such a thing to some extent... > > > Debian packaging/build system is used in Fink > > (for people unfamiliar with MacOSX:http://www.finkproject.org/) > > and there is also a FreeBSD port that uses > > Debian:http://www.debian.org/ports/kfreebsd-gnu/ > > Thus, yes, Debian is one such cross-platform system. > > OK, yes, it still needs some OS-specific glue, but not too much, and > > it runs atop of a Unix shell. > > > By the way, In Haskell there is a build environment (Cabal ?) similar > > to the Python's... > > > Dmitrii > > Caution, there's more than meets the eye. I don't get around to write > some Wiki page (which is overdue, sigh), so I write it here: > > Firstly, Sage has a "relocatability" or "prefix-ability", i.e. one can > install Sage anywhere in the file system tree where you like. For > reasons why one should want this to do in general, read about "Case 1" > in the following article: > > http://www.gentoo.org/proj/en/gentoo-alt/prefix/usecases.xml > > In contrast, "official" Debian packages want to put their content into > fixed locations. Of course, e.g. many autotool-based packages allow > for some option "--with_prefix=...". There are even package/install > systems to allow for that on a broad scale, like the Tcl-written > "Darwinports" (the "brother" of Fink), or the Gentoo/Alt "prefix" > project (from which I took the link above). But for Sage, this simply > is not enough. >
well, this does not mean that upstream packages, the source of which cannot be modified by sage, must migrate with the Sage installation... If you make a soft link to, say, /usr/lib/blah in a directory /tmp/z, and then move or copy /tmp/z somewhere, the link survives. > Since secondly, this "relocatability" or "prefix-ability" of Sage even > works after installation! One can install Sage in one subdirectory, > and then move its whole subtree elsewhere, and start it up there. > After some bookkeeping actions, Sage will work! This is important if > you e.g. distribute binary versions of Sage --- you'll never know > where the users are going to put it. In this case, Sage is not built > from source, and the sources of all the non-core spkgs are not > contained in the Sage binary distributions, so you just can't "re- > install" issuing another "./configure --with_prefix=SOME_OTHER_PLACE > && make && make install" sequences. I don't see how this makes impossible for, say, a Linux x86 binary Sage distro to use bzip installed system-wide... > Some users of Sage don't even have > a C compiler installed anywhere on their system --- and they don't > need to, in order to use Sage! This double nature of Sage being > distributable both as source as well as "pure binary" is quite > challenging, but rewarding. > > I hope you understand now, that the notion of "virtual packages" does > not fit too well in the Sage eco-system. OTOH, such a kind of > flexibility should be possible of course ... but not as easily as it > might seem. > > Cheers, > Georg best, Dmitrii -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
