On May 11, 9:41 am, Ondrej Certik <ond...@certik.cz> wrote: > 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? > That it wil be compatible with parallel building as mentioned earlier.
> Like if you want to install two packages that overwrite the same file? I don't think we should never do (or even want) such a thing. I think every spkg should only touch it's own files (or else we will get into an unpredictable mess if we also want uninstall and parallel building), if you really want an spkg to touch a file created by for example foo.spkg, one should instead make a patch for the foo.spkg. Maybe we should add some code that checks if there are spkg's breaking this rule. > > 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
