2009/1/7 Toshio Kuratomi a.badger@gmail.com:
Yaakov Nemoy wrote:
Hi List,
(Packaging list, i'm double posting because i want you guys to see this, but please put further comments on the haskell list :) )
Not subscribed to the haskell list and this isn't really a haskell specific question....
Point taken, continuing discussion here. CC'ing haskell list though.
Four comments:
- Why do we need to add this to the templates? All packages could
potentially be built from snapshots or built from releases. So I don't see why the Haskell templates should be special.
It's a special exception in this case. Many current releases of packages won't build under the ghc in rawhide. The tool i'm composing will make it very easy to track darcs and then switch to a final release once it's made.
- %darcs doesn't seem to be a good choice for macro name if it's
intended for use in the Haskell Guidelines. Perhaps this shouldn't be part of the the Haskell Guidelines?
Like i said before, please rename it. %darcs is a temporary name only, and i was looking for comments and suggestions. Would %darcs_timestamp be acceptable?
- The patch has two wrong Release lines, %{?darcs} should come before
%{?dist} but two of the patch hunks place it after.
I'll send an updated patch, though you have made some good points to abandon this strategy.
- Why not use a datetime string like the guidelines currently have in
place? You could use something like: DATESTAMP=date -u +'%Y%m%d' -d @`darcs-get-timestamp` sed "s/%define darcs ""/%define darcs "$DATESTAMP"/" -i foo.spec
This would be nice for inserting the proper defines. Actually, since this is python, i could probably script in a '-D' parameter to rpmbuild and mock as well. The tricky part is that there are three lines that also need to be edited, not just the %define line in the spec file. I have a couple of choices here:
1) Have fedora-devshell do something a bit weird and non-standard, that will leave a macro that may or may not make sense in the final submission to Fedora 2) Standardize a macro for those three lines, so that when i use #1, package reviewers and co-maintainers won't scratch their heads wondering what fedora-devshell is doing.
Given #2, that's what i'm asking for.