Hello, On Mon 24 Jun 2019 at 12:02pm +0100, Ian Jackson wrote:
>> A possible alternative would be to actually add --include-all-dirty, but
>> the problem in #914317 suggests that might not be a great idea.
>
> Your --include-all-dirty is roughly equivalent to -wn or -wdd ?
If -wn and -wdd imply not building in a playtree (I can't recall what we
decided there), I think that's right, yes.
> I think this is a useful behaviour for non-`3.0 (quilt)' packages.
> For `3.0 (quilt)' packages where upstream files are modified, it is
> even sensible with --quilt=nofix. The problems described in #914317
> occur with nontrivial quilt fixup modes, in quilt packages, only.
>
> (And this is true even after we support split brain with non-splitting
> quilt modes, since --include-dirty implies not building in a playtree,
> but split brain always involves building in a playtree.)
>
>
> Having thought about this some more, ISTM that: it is not really
> sensible to try to implement --include-dirty with building in
> playtree. That would involve trying to copy untracked stuff out of
> the maintree.
Certainly. --include-dirty should turn off building in a playtree.
> Therefore, any files which are not to be included in the result, must
> be deleted. (Doing otherwise would involve programmatic construction
> of dpkg -I -i options. Yikes.)
>
> Conversely, files which *are* to be included in the result could in
> principle be deleted *after* package building, but cannot be deleted
> before. I really don't think I want to extend the post-build stuff in
> dgit (currently just patch deapplication) any further. The tangle of
> execution flow is quite bad enough.
Er, yes, I don't see why deleting anything after package building would
be desirable. (Not sure what you have in mind here aside from
completeness in your reasoning.)
> What this means is that --include-dirty will always include precisely
> the things that were not cleaned. Any particular file is either
> included, xor cleaned. (Or causes dgit to barf.)
Yes.
> We already have 11 subtly different variations of --clean, to specify
> exactly which files should be tolerated and which cleaned. These 11
> variations are therefore precisely the possibilities for
> --include-dirty's unclean file handling.
Assuming those 11 variations are exhaustive of the possibilities, yes.
> Can we express this situation somehow in the manpage definition for
> --include-dirty ? Something like:
>
> Note that dgit will still clean the working tree before building the
> source packsage. Depending on the --clean mode, files not tracked
> by git, and/or files deleted by debian/rules clean, are at risk of
> being deleted, rather than included in the built source package.
> Consider passing a --clean= (-w...) option along with
> --include-dirty.
>
> maybe.
I think this is unnecessarily demanding of the reader as compared with
my proposed patch.
I'd suggest just updating my patch to say "you can use --clean=none or
--clean=dpkg-source[-d] in addition to --include-dirty".
> Should --include-dirty --quilt={linear,smash} be treated as
> --quilt=nofix ?
Is what you have in mind, here, helping the user avoid hitting the
#914317 problem?
--
Sean Whitton
signature.asc
Description: PGP signature
