gri6507 wrote: Hi,
> I've posted several thread on this topic now - mostly with question. > But now, with the help of several members in this forum, I finally > have my first release of an RPM (see > http://www.mypclinuxos.com/forum/index.php?topic=1509.msg13310#msg13310) > > I now want to do two things. The first is to trim down the size of the > RPM by stripping out content that is simply not necessary. To do that > I'd like to ask here if you believe the following directories are > needed in the "make install" process: > > /usr/lib/sage/data/extcode/.hg/ > /usr/lib/sage/local/bin/.hg/ > /usr/lib/sage/spkg/base/.hg Those repos are used in the development process. From our end it is always assumed that each Sage install, even the binary ones can do development out of the box without the need to install anything. Removing those repos makes that harder/impossible. Maybe that assumption does not hold any longer for a certain target audience, but I would suggest that you package those components in a sage-dev.rpm for people who want to do development work. Otherwise they will end up hearing "just install from vanilla source" from us anyway. > /usr/lib/sage/spkg/build > /usr/lib/sage/spkg/optional (possibly don't deliver what was already > installed?) > /usr/lib/sage/spkg/standard (possibly don't deliver what was already > installed?) Those should be empty or the content of the spkg replaced by dummy files. If you do not have those in the installed version any attempt to upgrade will fail or you will end up redownloading and rebuilding all components. Since those dummy files are all very small I don't think removing those will have an impact on the rpm size. > The second thing is still in the works. Since a number of libraries > built by SAGE already exist on the system, I'm working on modifying > the SAGE build process to pick up those instances instead. I still > have a while to go, but it's well on its way. I'll post my progress on > this part later. Well, the idea with the Debian effort is to update the distribution's packages to the version we ship or alternatively update our packages if the ones on our end aren't uptodate. 2.10 will make a large step toward updating spkgs on out end. I would also think that a monolithic rpm of Sage is of little use versus the tarball. If you end up replacing components please make it clear via some version string that you are shipping a modified version of Sage since otherwise we might end up chasing bugs in the components that your distribution ships. The tight integration of Sage was done for specifically this reason, i.e. just assuming that components on people's systems do work ended up being a support nightmare. It will also be hard for to keep up with the spkg changes on our end if you go into individual spkgs and adjust certain targets there. One option would be to "skip" over certain spkgs, but in some cases we patch packages [NTL for example is patches with a patch that makes Singular's omalloc work] and having a vanilla NTL in those cases will cause crashes/odd behavior. Don't get me wrong on the above: We welcome packaging efforts, but I think the way we go with Debian is the better approach. As other people have seen: even changing something simple like to another version of gmp causes performance regressions in certain situations as well as plenty of doctest failures. You have been warned :) Cheers, Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
