Hello, On Mon 30 Jul 2018 at 11:37AM +0200, Johannes Schauer wrote:
> my problem with adding the --no-source-only-changes option is, that sbuild > already today has a ton of command line options. I even know of blog posts > that > specifically lament the hell of options that they are confronted with when > they > open the sbuild man page. > > This is why, when introducing a command line option, then it should be one > that > is really necessary or otherwise it will further clutter the available space. > > My fear is, that after introducing --no-source-only-changes, then somebody > will > find another option that needs to be introduced for an sbuild wrapper to work. I saw one of those blog posts too, and I have a few responses. Firstly, --source-only-changes already exists, and --no-source-only-changes is just the inverse, so it does not really add any more material that a user must understand. Secondly, please do not assume that everyone reacts the same way to the sbuild manpage :) When I type `man sbuild`, I am happy to see so many options, because it means that sbuild is powerful and highly configurable, and I can probably make it do what I need. Thirdly, there are better way of controlling the presentation of documentation: for example, you can separate reference and tutorial documentation. We had a similar problem with dgit(1) and git-debrebase(1) that you are having with sbuild(1). Our solution was to add dgit-maint-*(7) manpages that help a new user get started. Once you are comfortable with the tools, you can look at dgit(1) and git-debrebase(1). Maybe you need sbuild-tutorial(7)? > Do we know that there is really no other option that dgit needs? It's highly unlikely, because we use sbuild in quite a straightforward way: feed it a .dsc, and take from it a binary-only .changes and its binaries. > Another thought: Currently nothing prevents the user from typing: > > % dgit sbuild --source-only-changes > > So maybe there is a better way to do things? Ian and I talked about this and we decided that if the user passes this option, they get to keep the pieces. As I said, we don't want to be a full wrapper for sbuild. The only other thing to pass is #904862. > As you argued, it might be important that sbuild reads the user's > ~/.sbuildrc, so how about the following solution: > > Let dgit run sbuild in a temporary directory, and then whatever files > sbuild creates will not conflict with the files dgit creates. Dgit > could then just retrieve the files it needs from the temporary > directory and then delete the directory. This also makes sure that > there are no further clashes in terms of files sbuild creates. For > example: there is an open bug against sbuild that asks whether it > would be possible for the user to specify a custom pattern of how > sbuild names the .changes file. Now suppose the user ends up using the > pattern that dgit chose. Hmm. This is an interesting suggestion. I should explain exactly what can go wrong if the user *does* pass --source-only-changes: if sbuild overwrites the _source.changes, the -v option passed to dgit will not take effect. We haven't tested extensively, but we think that that's it. Given that what can go wrong is not all that serious, the solution you propose seems like overkill when compared to adding the inverse of --source-only-changes to sbuild. -- Sean Whitton
signature.asc
Description: PGP signature
