[Fedora-haskell-list] Re: [Fedora-packaging] Update guidelines for using darcs based sources in packages

[Yaakov Nemoy]

2009/1/7 Toshio Kuratomi :
> 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.