Oh, thanks for multiple response, some comments: @ Robert Bradshaw: > There's a lot of > hard and symbolic links laying around. Having the source around is > important for debugging and tracebacks (not just for development).
Right at the moment its not just links, but real files, some of them in 3 directories. At some point (in the future?) there might be a stable core functionality, so debugging may become less important in the vanilla installation. > > I imagine that the reason this is not done is so development is "at > > hand" to any user, and so there would be more chance of them > > contributing. I think this is true. > > +1, which has been essential to getting Sage where it is. Contribution can also involve other areas (Documentation, Promotion, Testing, Application, Teaching). I think the vast majority of potential users will not contribute code to the core of sage - at least not in the beginning ... > The binaries do have empty spkgs, but I find it interesting that in > this day and age people would find, say (optimistically) 200MB small > enough but 350MB too big. Right at the moment the binary distribution produced by the default procedere is 449 MB in a squashed filesystem for me. It was 387 MB in Version 4.3.1 - this is a significant increase in 6 months. The 350 MB can be reached by lzma-ing (as far as I know), but that is not usable in my install. "Size" is also not only about "Download size". Away from "too big" or "small enough", let me put it this way: maybe it is possible to make it smaller without loosing functionality for normal operation. > Size is a concern, but mostly comes into > play when deciding whether it's worth including an spkg or some > pre-computed data. Idea: If the core is slim, one can use extra spkg (specialised in application field). @ Justin C. Walker: > I think you'll find that stripping (dynamic) libraries is counter-productive. > But try it and let us know how it works :-} I am pretty ignorant, I am using Puppy Linux, which has the character and flair of a hobby-distro. But it sure it has some merits in offering great functionality using minimal space (250 MB with complete set of applications and full development environment). If I look into the lib folders I see only stripped dynamic libaries, I guess it has a reason. What would be the disadvantage of stripped libraries? My knowledge is, that debugging information etc is ommited. What else? And I will try it :-) ! >I suppose it's worth considering a "really binary release" I could make good use of such a package for the live CD. I intend to dig into it and try to make a one plus an additional "sage_dev" package (mid-term goal: make a procedure for it to have it automated for future releases). But for the uninitiated it is not obvious which files and folders serve which purpose. I hesitate to start one of my usual a trial and error approaches. just take the mentioned directories as examples: Intuitively I would assume /devel/sage-main/sage contains the "real" binaries everything in /devel/sage-main/build is necessary for development. Right or wrong? > that is of use only for those that don't intend to add to the Sage project. As expressed above: there might be additions and contributions beyond code ... I would be grateful to get any advice about the structure of the sage directory tree, is it realistic to build such a "dev" package, if yes: which files can be shifted? emil -- 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
