Re: How to remove extra files created when building a package?

[Thomas Nyberg <tomuxiong@gmx.com>]

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