Thanks for all the helpful info!
On 06/29/2017 09:15 PM, Sven Joachim wrote:
> On 2017-06-29 20:36 +0200, Thomas Nyberg wrote:
>
> In my experience, if you are serious about changing packages it's always
> better to create a git repository, if only temporarily. Ideally clone
> the existing one mentioned in the Vcs-Git header, but this might be too
> big or too outdated, not even containing the changes from the latest
> upload. Or create your own from scratch, e.g. with
> "git init; git add .; git commit -a -m 'Initial Import'" .
>
I see. Yes the easiest would probably be to remember to always
initialize a fresh repository. Or I could also just copy the directory
itself before messing around (since I don't care much beyond the
original version in a simple patch like the one I applied).
>
> If you have already built the source package, the easiest way is to
> throw away the mess in the current directory and unpack afresh.
>
This is what I would have done, but I'm currently on a pretty bad
internet connection. I originally downloaded the package with
$ apt-get source thunderbird
That produced a few different files in the directory I was in. The one
that I messed with was the `icedove-45.8.0/` directory. Is there a way
to regenerate the `icedove-45.8.0` in its original state from the others?
>
> Yes, that is considered a bug. Debian Policy ยง4.9[1] states the
> following about the clean target:
>
> ,----
> | clean (required)
> |
> | This must undo any effects that the build and binary targets may
> | have had, except that it should leave alone any output files
> | created in the parent directory by a run of a binary target.
> |
> | If a build file is touched at the end of the build target, as
> | suggested above, it should be removed as the first action that
> | clean performs, so that running build again after an interrupted
> | clean doesn't think that everything is already done.
> `----
>
> However, with the rise of packaging helpers like git-buildpackage,
> people seemed to have stopped caring about this problem since they
> always build the package in a scratch space. And this approach (which,
> incidentally, has been used in the RPM world for ages) certainly has its
> merits, since it completely sidesteps the problem of backing out any
> changes the build process makes to the source tree.
>
Does it make sense to provide a bug report? I agree with you that it is
a bug according to the policy, but if the community is moving away from
this process, maybe I'd just be a pain?
Thanks again for all the information!
Cheers,
Thomas
