Re: [sage-release] Re: New guidelines for spkgs

2014-01-23 Thread Jean-Pierre Flori
To be completely clear, two additional questions:

On Thursday, January 23, 2014 10:57:29 AM UTC+1, John Cremona wrote:

 Here is how I have interprested these questions for the packages I am 
 involved in maintining: 
  * package-version.txt, should it only be updated when the tarball 
 changes? 
  this is what 
  http://www.sagemath.org/doc/developer/packaging.html#package-versioning 
  suggests, not what the discussion between Jeroen and I at 
  http://trac.sagemath.org/ticket/15123#comment:32 did. 

 Yes.  It's a label for the upstream version.  Local changes to what we 
 do with the tarball are tracked by git anyway. 

 Is this enough to trigger a package rebuild if you for example add a patch?
 

  * history in SPKG.txt, 
  http://www.sagemath.org/doc/developer/packaging.html#the-spkg-txt-filesays 
  no history anymore, so should we just get rid of the old history when 
  updating? as remarked http://trac.sagemath.org/ticket/15123#comment:24it is 
  still available in the hg/git history (and I'd better have no info kept 
 in 
  SPKG.txt than just old info). 

 Correct:  the new SPKG.txt does not contain its own update history. 

 So you actually removed all the old info stored there? 

Best,
JP

-- 
You received this message because you are subscribed to the Google Groups 
sage-release group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-release] Re: New guidelines for spkgs

2014-01-23 Thread Jean-Pierre Flori


On Thursday, January 23, 2014 12:07:44 PM UTC+1, John Cremona wrote:

 Yes, I was told that upstream tarballs should not contain any Sage 
 changes, those should be done via patches in the install script.  And 
 hence upstream tarballs should not have any .p in them.  I did that 
 wrongly when I redid the database_stein_watkins optional spkgs for git 
 and was told to change it by Jeroen. 

Sure, I definitely agree about not patching upstream tarballs, except 
that some upstream tarballs are not really vanilla:
* some stuff might be deleted to save space (and I just would like to 
delete a little more in ECL than used to be),
* some autogenerated additional stuff might get added (see the custom 
autotools project for ATLAS),
* some addiitonal binary  might be added (see the archdef tarballs for 
ATLAS).
This situation is kind of exceptional but still problematic.


 Someone like Volker as release manager should probably tell use the real 
 story. 

 Sure, just waiting for some feedback to unlock some tickets. 

And thanks for your replies!

-- 
You received this message because you are subscribed to the Google Groups 
sage-release group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-release] Re: New guidelines for spkgs

2014-01-23 Thread Volker Braun
You *should* not change upstream tarballs. Sometimes, we have to. There is 
no good way to change the upstream tarball without changing the version 
number. Arguably, thats a feature. Maybe use package-2014123.tar.gz if you 
have to.

There is no point in a spkg-src script if the tarball is not modified. Did 
you forget how to download files? ;-)

Right now, only the package-version.txt timestamp is used in the makefile 
dependency calculation. So you have to add a .pX to the version number 
there (but not in the tarball) to trigger a rebuild if necessary.  (*)

Feel free to strip out the old changelog from the SPKG.txt file, but please 
no autogenerated patches that do it globally.

I'm against boilerplate copy-pasta in spkg-check/spkg-install files to 
check that we are really being called from Sage.  (*)


(*) these really ought to be addressed in future changes to the build 
system.

-- 
You received this message because you are subscribed to the Google Groups 
sage-release group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/groups/opt_out.