Re: RFS: lockrun
On Wednesday 18 June 2008, Noah Slater wrote:
--cut--
Hello, and sorry for the late reply,
> > Seems like cdbs magic doesn't cope with that, but you can still save the
> > day: clean:: unpatch
> > common-install-prehook-impl:: patch
>
> This is a bug in CDBS, I have reported it as #486848:
>
> http://bugs.debian.org/486848
Sure.
> I have added the following line as a temporary workaround:
>
> binary-arch binary-indep: build
Fine.
> > 2) Regenerating source files (the sed line) during the build process
> > could be a weird source of troubles. Next, we end up having one single C
> > file and two ways of modifying it
>
> This has been changed so that we generate lockrun.sed.c from lockrun.c
> instead.
>
> I don't really see any problems with this method.
A possible problem could arise when users of your source package decide to
exemine the source code and call fakeroot debian/rules patch, but there is
still modification left (no matter how innocent it is) to be done against the
C code during the package build time. This is not very consistent behaviour
unless s/he realizes to exemine your rules file more closely and issue the
sed line themselves. Can you think of a solution where your
command-option.patch and sed modification could be applied by the patch
target ? It is possible, and consider it a wishlist. OTOH I would be fine if
someone upload it the way it is.
> > 3) No diff.gz found on mentors - probably a native package done by
> > incident ?
>
> Yes, sorry about that, my mistake. Fixed now.
OK.
> > 4) You can add a watch file, also.
>
> The upstream does not use version numbers so a watch file would be
> pointless.
You are correct, I forgot about that. I believe it would be best to discuss
with upstream to provide any decent versioning scheme, which would let you
avoid constructing upstream version from the debian version, not that it is
bad, it is just not optimal imho ;-)
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Reply to: