octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: package system


From: Søren Hauberg
Subject: Re: package system
Date: Tue, 09 May 2006 20:32:10 +0200

tir, 09 05 2006 kl. 13:55 -0400, skrev John W. Eaton:
> Sorry for the delay in doing anything about the package system.  I'm
> ready to include it in the Octave archive CVS now with a few changes.
> 
> In the 0.2.1 version of the package code (is this the latest, or have
> there been any changes?)
For some odd reason I never uploaded my latest changes, so the answer is
no 0.2.1 is not the latest version (sorry). I'm attaching the latest
code.

[snip]
> I'd like to make everything a "private" function except something like
> "pkg" or "package" which would then be called by users like this:
> 
>   pkg list
>   pkg list-installed
>   pkg show
>   pkg install pkg_1 pkg_2
>   pkg remove
> 
> etc.  The pkg function would be implemented using functions based on
> what we currently have.
We talked about this earlier and the attached code works this way.

> The package-0.2.1 directory also includes rm_rf.m and untar.m.
> 
> Perhaps the untar function should be converted to a generic "tar"
> function?  Or we could just have a specialized __pkg_unpack__ function
> that does just enough to implement unpacking of the package files.
untar.m has a syntax almost identical to the matlab untar function, so 
I think untar.m should be added to octave. I'm also attaching tar.m and 
unzip.m. I think these functions are part of "basic" matlab.

> The rm_rf function makes me nervous because I imagine some luser
> installing precious files inside a package directory and then removing
> the package later and blaming us for wiping out decades of valuable
> work.  Or, disaster could strike if a bug caused a bad directory name
> to be passed in (rm_rf ("/") --- oops!).  So I think it would be
> better for each package to contain an explicit list of files and then
> we would only delete those files from the installation directory.  We
> could remove plain files first, then remove directories with rmdir and
> issue a warning if the directory can't be removed because it is not
> empty.  For the plain files, we could keep a checksum and only remove
> unmodified files.
I agree that rm_rf shouldn't be a user-visible function. The reason for
having the function was to seperate out all parts that depend on unix,
so a windows version would be more easy to create.
When I wrote the code I decided not to keep track of individual files to
keep the code as simple as possible. This is the reason packages are
installed in separate directories, because then uninstallation is very
simple. We could keep track of individual files, but is it worth the
hassle? 

> Comments?
Tom just asked if the package system downloads packages automaticly. It
doesn't, and I agree that it shouldn't. It's just too hard to get such a
system right.

> 
> jwe
Soren



reply via email to

[Prev in Thread] Current Thread [Next in Thread]