On May 16, 1:08 am, Keshav Kini <keshav.k...@gmail.com> wrote: [...] > What I am proposing (and I guess it's similar to what Robert was > saying): > > The package named foo consists of some files and directories created by > Sage developers, and some files created by upstream developers. The > files and directories created by Sage developers are shipped as part of > Sage - not in a tarball, just in the file tree. The files created by > upstream developers sit in a tarball. That tarball can be shipped with > Sage, or not. The foo-related files created by Sage developers and > shipped in the Sage tree include a datum which gives a location of the > upstream tarball, either as a path in the Sage file tree, or as a URL > for an external downloadable file.
How would that approach work when the "upstream" needs both cruft removal and patching? From your description I understand that the script doing the patching would live somewhere in the sage tree. Where would we document (either in the form of instruction or preferably in the form of an automated script that takes a truly upstream tarball/ repository/whatever and extracts from that the tarball we're interested in) the procedure to produce the tarball? Does this live (as it does now) as a spkg-make script (etc) and/or as part of a README inside of the "tarball"? Or do we put TWO procedures in the sage tree: 1] procedure to produce a tarball from sources truly outside of sage's control 2] procedure to take the content of the tarball and use that to build the appropriate libraries, executable, whatever the functionality is that the spkg provides. The idea of the split in procedures is that 2] is supposed to be executed whenever the component is "installed", whereas 1] is only supposed to be performed for upgrading the component and the result of it is shipped with sage (for standard) or stored elsewhere (for optional) For some operations it seems a bit arbitrary where they would fit. Why should only cruft removal go into 1] and no patching? Is that just a judgement call, that step 1] should be kept minimal while still producing something that is acceptable to ship? If so, is there a clear reason why step 1] should be minimal? It's clear that anything that might be architecture- or system- dependent should be run in 2] (such as running configure, make, and install), but I don't think we ever patch dependent on architecture. In that case, you'd write a patch that can be applied unconditionally and contains the appropriate architecture tests . So for functional reasons, it seems patching could happen in step 1] too. Of course this is all just package management, so by all means, do whatever works best/is most convenient. However, in my experience, procedures tend to work better if there is some simple conceptual reasoning behind them. -- 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
