On Jul 20, 4:21 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
Hi, > > OK, so who knows a clever way to detect which files were added/changed > > in a directory structure? > > Quick and very dirty : 'find . -cmin -5' (files modified less than 5 > minutes ago). Not even close :). There are packages that install in less than 10 seconds. > Quick and dirty : ls -lR > before ; make install ; ls -lR after ; diff > -u before after | sed -e 'whatever_to_prettify_the_output' but it will > look kind of ugly. Better. > Better : make a decent snapshot of the tree state before installing, > keeping track of filename, modification time, size, possibly some md5 > checksum or something (say in an sqlite database file, easy to do in > python), and compute the difference after running make install. I am not so sure this is worth it. You are basically writing apt/rpm for user space. And we like to reuse components if they exist and fit the bill :) > But once you are there, you might as well keep the snapshot, add the > package name as one of the file attributes, and bam you have a package > management system ! But this is IMHO not KISS - a guiding principle of Sage :). Right now a fresh 3.0.6.alpha0 contains about 107235 files in $SAGE_LOCAL when following symbolic links. That is a lot of IO and disk seeks to do to upgrade for each package. One thing that endlessly annoys me about rpm for example is its sluggish performance, which is largely rooted in its db backend, i.e. berkeley db IIRC. On top of that sqlite's performance sucks even worst. And you also introduce another point of failure where up to now KISS had provided a nearly perfect solution, i.e. any sort of db corruption will break Sage's upgrade system. > /v I *really* like the idea for optional packages, but for the core there are various problems you will have to deal with: * Updating one spkg often forces the update of another spkg. For example updating clisp forces a recompile of Maxima. So you cannot just switch between two clisp installs and expect things to work. And there are even more complicated dependencies in the default tree. * The Sage library is special and there are loads of subtle dependencies. For example 3.0.3 to 3.0.4 upgraded LinBox from 1.1.5 to 1.1.6.rc0. A seemingly innocent update until you learn that this also means that the name of the wrapper library has changed. So running a 3.0.4 or later Sage library with a linbox-1.1.5 or earlier will cause Sage not to even start any more. In some cases it is imaginable that Sage does start but will exhibit subtle bugs since we fixed something in FOO-1.3.3.p12, but for some reason one user ends up running FOO-1.3.3.p11. Happy bug hunting in that case. * sage -upgrade will be completely broken by introducing the framework you envision. We could disallow upgrading of Sage at some point so that everybody would be forced to start with a clean tree, but so far that has never happened. * Once sage -upgrade works you will end up with ever increasing install sizes of Sage. You can obviously prune the tree, but just the other day I removed about 5 GB of spkgs from two Sage installs that have been updated for a while and actually caused the notebook to crash due to lack of space on the harddisk. Now imagine what those Sage trees would take up on disc if all those spkgs had not been overwritten. Due to the above I don't think using anything like you propose for the core is a good idea. I have changed my mind on fundamental issues like this before (usually from negative to positive once an implementation actually existed), but so far the bad does outweigh the good by a mile. We do KISS for a reason :) But please do not be discourage to attempt to make it work. Cheers, Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
