> > 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.
> 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.
> > 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.
> 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.
> * 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.
> * 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 ?)
> * 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.
> 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 :->)
Cheers,
/vincent
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
