Ian Jackson:
Sean Whitton writes ("Bug#1079762: dgit: Supporting generated files (`debian/control` and `debian/tests/control`) not commited to git"):Is that the sort of committing-of-generated-artifacts you object to? Or is it okay if the maintainer never sees it?For comparison, some of the best workflows for generating "3.0 (quilt)" .dscs also commit output files, namely debian/patches. In those workflows the primary representation of the patch queue is in git commits, and the in-tree version is there for compatibility with dpkg-source. git-debrebase does this when used with "3.0 (quilt)". I believe that some other tools like git-dpm and git-debcherry do too. > ISTM that debian/control could be thought of similarly.
I am perfectly fine if `dgit` creates a commit on the `dgit` branch to include the generated files for `dgit clone` to match the uploaded source package. If that is what happens with `git-dpm` / `git-debcherry` then yes, `debian/control` would be similar.
One key question is: what happens if you start with transformed view, the edit the package? Either the generated files or the inputs. Ian.
I have not met "transformed view" before. I am going to answer on the assumption that you mean the `dpkg-source -x`/`dgit clone` view. This would be similar to the work flow for NMU'ers and I will frame my answer in that narrative as it would also interact with merging back the changes.
I will start with the maintainer VCS. For the sake of understanding, I will introduce `debian/control.in` as a fictive input file that is used as a part of the generation. The filename keeps the example simpler/more intuitive for now even if it might work differently in the end.
The maintainer VCS would contain the three files: debian/changelog [v1] debian/copyright [v1] debian/control.in [v1]With [v1] denoting a version to mark when a file changes. When the maintainer builds the package, `debian/control` + `debian/rules` will be generated and injected leading to the source package:
debian/changelog [v1] debian/copyright [v1] debian/control.in [v1] debian/control [v1 (generated from v1)] debian/rules [v1 (generated from v1)]If someone downloads the source package and unpacks (`dpkg-source -x` or `dgit clone`; either way) that is what they will see.
For sake of simplicity, I will keep the changelog unchanged even if it is unrealistic. But it would be one extra moving part for us to keep track of and it does not change the cases in any meaningful way.
## Case 1: Modifying `debian/control`Lets say they modify `debian/control` but not `debian/control.in` and then rebuild the source package, then you get:
debian/changelog [v1] debian/copyright [v1] debian/control.in [v1] debian/control [v2 (generated from v1 + manual edit on top)] debian/rules [v1 (generated from v1)]Only `debian/control` changes in this scenario. This comes from the rule if `debian/control` exists then auto-generation is disabled.
This is a deliberate strategy for statisfying the FTP master rules but also to ensure NMUers/NMU tools are not required to know about this generation mechanism.
This case works the same if it had been `debian/rules` that was changed. ## Case 2: Modifying `debian/control.in`Lets say they modify `debian/control.in` but not `debian/control` and then rebuild the source package, then you get:
debian/changelog [v1] debian/copyright [v1] debian/control.in [v2] debian/control [v1 (generated from v1 - v2 was ignored)] debian/rules [v1 (generated from v1 - v2 was ignored)]In this scenario, basically nothing changes. This comes from the rule if `debian/control` exists then auto-generation is disabled. This is a side-effect of the strategy from Case 1.
Best case, the tooling might detect it and warn about it. But it is "working as designed" to match the constraints.
The NMUer would have to either manually apply the edits to `debian/control` as well or use Case 3. Otherwise, 2 is a dead edit and de-facto a no-op if no further edits occur later.
While this case can happen by mistake, I do not see it a real case. If a NMU'er uploaded this, they would likely realize their change had not taken effect and then re-upload with case 3 to finish their change.
## Case 3: Modifying `debian/control.in` + deleting `debian/control`NMUer modifies `debian/control.in` and deletes `debian/control`, then rebuilds the source package. This leads to:
debian/changelog [v1] debian/copyright [v1] debian/control.in [v2] debian/control [v2 (generated from v2)] debian/rules [v2 (generated from v2)]Note `debian/rules` gets regenerated as well based on the spec I provided (whether that is the correct approach might be a question - particular related to merging back part, but for now this is what would happen). Additionally, new files could be generated if the generator is of a newer version and picked up more features since the original source package was built.
In this scenario, files are regenerated from the new input file no different than if you had started from the maintainer checkout and edited `debian/control.in` from there.
## Case 4: Modifying an unrelated file Lets say they modify `debian/copyright`, which is not used in generation: debian/changelog [v1] debian/copyright [v2] debian/control.in [v1] debian/control [v1 (generated from v1)] debian/rules [v1 (generated from v1)]This case is basically the same as it was before this spec from the NMU'er PoV, but it affects the maintainer on merging back the NMU. Since `debian/control` exists, the auto-generation does not kick in.
Note: It is quite similar to case 2, but I kept them separate deliberately to cover them both separate for the sake of clarity.
# Merging back into the maintainer VCSAssuming the change was an NMU, it will eventually be merged back into the maintainer view. My line of thinking is that the maintainer will have to review the generated `debian/control` and `debian/rules` files for changes.
So for case 1, the maintainer would have to manually extract the delta from `debian/control [v2 (generated from v1 + manual edit on top)]` and apply said delta to their current version of `debian/control.in`. With most `merge NMU` tooling (`dgit` or `gbp import-dsc`), the maintainer would also have to `git rm debian/control debian/rules` to restore the auto-generation. UX improvement here would be if we can get `dgit`/`gbp import-dsc` to force the `debian/control` into a merge-conflict state since there is a delta and discard `debian/rules` since `debian/rules` was unchanged. Not sure about the feasibility of this UX part.
For case 2: I do not see that as a real long term case (I think an NMUer would redo their upload, so it follows case 1 or case 3), so I am leaving this one unanswered.
For case 3: The merge would include `debian/control.in` (real value) plus `debian/control` + `debian/rules` (noise; to be deleted). Maintainer would merge and delete the two noise files. UX improvement here would be if the merging tool (`dgit`) could catch the noise files as auto-generated from the updated `debian/control.in` with no delta and discard them automatically on merge. Not sure about the feasibility of this UX part.
For case 4: The merge would include `debian/copyright` (real value) plus `debian/control` + `debian/rules` (noise; to be deleted). Maintainer would merge and delete the two noise files. UX improvement here would be if the merging tool (`dgit`) could catch the noise files as generated with no delta and discard them automatically on merge. Not sure about the feasibility of this UX part (but it would likely be easier than case 3, since the files are unchanged since the maintainer upload).
That is how I see what would happen with this proposal if you work from the `dgit clone` / `dpkg-source -x` with the files generated. Hope that answered your question.
Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
