Le jeudi 17 mai, Robert Bradshaw a écrit:
> On Wed, May 16, 2012 at 11:34 PM, Julien Puydt
> <julien.pu...@laposte.net> wrote:
> > Le mercredi 16 mai, Robert Bradshaw a écrit:
> >> I don't like spkg.txt because it's just a (under-specified)
> >> convention of what to put there when you make manual changes.
> >> Better would be to have some specification file (json?) like
> >>
> >> { upstream = "http://original.project/releaseX.tar";,
> >> upstream_sha1 = "...",
> >> excise = [ "windows.exe", "binary.blob" ], # remove from the
> >> above when creating our tarball (below)
> >> sources = "project.X.tar",
> >> sources_sha1 = "...",
> >> patches = [ "fixOne.patch", "fix2.patch" ], # to be applied to
> >> sources, once unpacked
> >> }
> >>
> >> Then an spkg could be automatically generated by changing the
> >> upstream url (most common case), and otherwise one could
> >> tweak/meddle with src and automatically create a new patch once
> >> you get it working.
> >>
> >> This may be a pain to do with shell scripts (how do you parse a
> >> json file?) but perhaps a lot could be cleaned up if we assumed
> >> *some* python as a prerequisite.
> >
> > May I suggest that instead of writing JSON then trying to parse
> > it... just write a shell script (see below for the type of shell
> > script I have in mind)?
>
> Parsing JSON is easy in a proper language with the right libraries,
> and easier to manipulate and re-write programmatically (e.g. when
> automatically creating the patch files). I could see storing other
> metadata (including dependencies) in that file as well that one would
> want to reason with. The makefile idea has merit though.
In debian packages, there is :
- a 'control' file which declares what the package is about, including
dependencies ;
- a 'rules' file, which is a Makefile, which can look like what I shown
(it's generally simpler since it can rely on things debian provides)
> There's 2 tarballs here, the actual upstream (that we don't typically
> ship with Sage) and the purged one (that we do).
Well, you could have a 'download' target to download the upstream and a
'sagify' target which would turn it into the other tarball (the one
which would actually be shipped or placed on sage mirrors depending on
mandatory vs optional status).
> > What use if there for a "patches=..." list if you have the patches
> > in a patches/ directory already?
>
> They may not commute. I suppose they could be numbered/otherwise
> ordered based on their names.
In debian, the patches get in a patches/ directory, named
01-foo.patch, 02-bar.patch, etc. And there is a patches/series
file which contains an ordered list of the patches (I haven't figured
out what it's used for since there is already an explicit numbering).
It would definitely help if more sage developers knew how things are
done in debian, fedora or gentoo -- the mail Harald Schilly sent
yesterday and the citation therein are spot on there.
Snark on #sagemath
--
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
