On Tue, May 10, 2011 at 11:23 PM, Maarten Derickx <m.derickx.stud...@gmail.com> wrote: > > > On May 10, 9:10 am, Ondrej Certik <ond...@certik.cz> wrote:. >> >> It just occurred to me, that it should be possible to keep the current >> SPKG format, and implement uninstall. One just needs to keep track of >> all files in SPKG_LOCAL, then see what new files were added + which >> files have changed. >> >> If a file has changed, then a warning should be produced, and we would >> look at each case manually. Maybe it's possible to make the whole Sage >> (or Qsnake in my case) to build without changing any files, just keep >> adding them. >> > > A brilliant idea. This allows us to transition smoothly to a more > distribution friendly setup. I'm interested to see a list of spkgs > which modify files (and offcourse the files being edited). > > Is SPKG_LOCAL really an environment variable used in sage? If so the > next step might be to temporarily change it to SPKG_LOCAL/
Sage uses SAGE_LOCAL, but SPKG_LOCAL is more project neutral, so I use that. > packagename.versionnr before each install of an SPKG and see what > breakes (probably a lot). But if we get things working again then > uninstall is just as easy as deleting a directory. This would make the > step to something like nix very small. > > Note that a lot of SPKG's also install stuff into something like > python*/site-packages. > > And I second the idea that the list of files should not be > autogenerated during install but be a part of the SPKG. Although the > initial file lists in the SPKG can be autogenerated offcourse :). What would be the advantage of having it in the SPKG itself? Like if you want to install two packages that overwrite the same file? Ondrej -- 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
