hi Didier,
On Jan 1, 2:41 am, "didier deshommes" <[EMAIL PROTECTED]> wrote: > 2007/12/31, mabshoff <[EMAIL PROTECTED]>: > > == Dependencies == > > > > > * gmp > > * pari > > * NTL > > I feel like this is too much information required for an spkg. It is information that should change rarely and is already present in deps, but will help out the packagers for distributions. Ismail for example has inquired about those issues repeatedly, so writing them down is a big plus in my opinion. > I think > that only the name, upstream contact and maintainers fields should be > required to distribute one. The changelog could be inferred from the > hg changelog, The problem is that the hg changelog itself tells only half the story, i.e. what changed in the base directory. But the SPKG.txt should reflect also what changes in the src directory and those changes should be on a very high level. The whole changelog is supposed to be in the wiki and I don't see any convenient way to extract that information from the hg repo in some automated way. And I do believe that if you take the time to summarize the changes you made to some spkg it will be better than a set of change log messages. And reading the diffs of spkg-install isn't an option in my opinion either. One should just spend a minimal amount of time to catch up with the changes and reading it in some text format or the wiki is the most convenient in my opinion. > the distribution field does not seem to be of any value to me as a user. Well, maybe not to you, but in case of problems with Sage packaged by a distributor in the future it will come in handy in my opinion. If somebody has a problem with Sage x.y.z packaged for FUBAR Linux when we are at Sage x.y+3.z+2 I would just point that person to said link/ contact if the person doesn't want to update to Sage x,y+3,z+2. I seriously doubt that we will ever support a "stable" release. William has speculated that we will do that "once things settle down", but I don't see that happening any time soon. Maintaining a stable release for a said amount of time could happen via some commercial support contract, but I see little value in patching some old forked code base. I looked at the Gentoo ticket to create an ebuild for Sage today and they had some patch that made sure that SAGE_FORTRAN didn't have a trailing slash or something. If I have all the URLs to the distribution packages in one location I can easily check them for patches. In a perfect world that wouldn't be needed since those should flow back freely from packagers, but in reality this takes time. I have been sitting on a lot of patches for Cygwin/FreeBSD/Solaris recently for a variety of spkgs and I will push all of those upstream in the 2.10 merge cycle. Another section that should be mandatory are all changes made to the original upstream sources, i.e. removal of documentation to shrink the size and so on. That section should be quite detailed, preferably with some script that does the job. That way somebody can adopt a package quickly when the original maintainer is busy or goes missing for a while. > > * How do we keep SPKG.txt and the wiki page in sync? In an ideal world > > we would just copy over the updated SPKG.txt into the wiki and be done > > with it. But people will edit the wiki page, i.e. to add contact info > > or correct issues. One way would be for the maintainers to subscribe > > to the pages of the spkgs they handle and sync it manually. Since the > > wiki preserves all edits and offers an interface to diff this should > > be relatively easy. > > That's a great solution. > > didier 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/ -~----------~----~----~----~------~----~------~--~---
