On Jul 21, 6:18 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
Hi Vincent, > > > 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. > > That one was a joke, of course. I have used it occasionally for a > punctual problem, but it's not for packaging. Ok, you can never be sure around here what people propose :) > > 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 :) > > apt/rpm are way too big for my purposes, I am not even sure I want to > consider dependencies between packages just yet. Well, my argument is that once you have the system in place sooner or later someone will suggest and/or implement dependencies and so on. That does not have to happen obviously, but people are packaging Sage for distributions where such mechanisms are already in place. > > > 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. > > Yes ! I totally agree with you, it is completely unacceptable to > traverse the whole Sage directory at each package installation. Which > is precisely why we need DESTDIR in every scenario I can think of. > Once you have that and you keep track of package manifests for > removal, you do in fact have the bare bones of a package manager. Ok, I kind of thought that I made the wrong assumption there and that my argument was slightly idiotic, but it was late and I was tired :) > > 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. > > About sluggish performance, I was in the train without a Sage > installation but I started to play around with pysqlite. Given that > mathematicians tend to keep on themselves (the extrovert ones are the > ones that look at _your_ shoes ;->) :) > I thought it was a good idea to > package GNU hello for inclusion in Sage. I built a fake sage directory > our of random parts, it has around 15k files. Built a sqlite database > for it, and timed the hello-related commands : > > Extraction of the tarball : approx. 1.3 sec (oldish G4 powerbook, > unplugged, bare with me ...) > ./configure : 41 sec (yes, my laptop is old I told you) > make : 6.4 sec (see above) > make install : 7.5 sec (same time going to $SAGE_ROOT or to a staging > directory) > SPKG.insert : 0.4 sec (moves the files from staging to $STAGE_ROOT and > updates the database) > SPKG.remove : 0.4 sec (removes the installed files for hello, updates > the database) > > So the overhead of the database appears to be minimal. Admittedly my > directory is too small by an order of magnitude, but still I don't > expect the overhead to grow out of bounds. I would call a 5% overhead > at install time within the bounds of reason. Sure, overhead is one concern, but over-engineering another. One example (and I know this is not fair to compare your proposal) is the Windows registry. Sounds like a great idea until you realize that having config information in text files is much smarter in the long term. Another example is to stuff everything into XML files since it is so great and cool, but in the end the vast majority of situations is much better served by plain flat text files. So where is the benefit from using a database or even keep a list of the files? I just don't see it. > > * 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. > > As I said, I am not intending to manage package dependencies just yet, > just removal. Ok. > > * 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. > > (Then it appears that a non-working transient state is unavoidable, > isn't it ?) Yes. If you develop or work on Sage spkgs you likely learn how to up- or downgrade spkgs and/or learn to look at changelogs of alpha and rc releases to figure out what is going on. Just as above: What is the benefit of all this to the user of Sage? I see it for some optional spkgs, but not for the core. > > * 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. > > Point taken. Yes, but this problem can obviously be solved. > > 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 :) > > I will keep the list informed as I go. Not desperate yet ! And even if > the system is only for optional packages, it would still be a useful > addition to Sage. (As opposed to, say, GNU hello :->) Yes, I agree 100%, but I would prefer to do something simple with a couple lines of shell, i.e. build an optional spkg with ./configure --prefix=$SAGE_LOCAL/optional/foo-0.1 and then extend PATH, LD_LIBRARY_PATH and PYTHON_PATH as needed. For that we don't need some (ugly :p) Perl script that on top is also dependent on some Posix shell features when we can do something simple that works in the generic case. > Cheers, > > /vincent Cheers, Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
