Bug#904968: sbuild: please add --no-source-only-changes option
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
Bug#904968: sbuild: please add --no-source-only-changes option
Hi Sean, Quoting Sean Whitton (2018-07-30 10:50:32) > > is there any reason why dgit does not set the SBUILD_CONFIG environment > > variable to either an empty value or to a config file that lets sbuild do > > exactly what dgit expects it to do? > We are not trying to be a full wrapper for sbuild. The user's config should > be allowed to take effect. For example before an upload I type > > % dgit sbuild --run-autopkgtest --run-piuparts > > but autopkgtest and piuparts will not work without my .sbuildrc. > > Generating a _source.changes is the only option that we must turn off. 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. Do we know that there is really no other option that dgit needs? Another thought: Currently nothing prevents the user from typing: % dgit sbuild --source-only-changes So maybe there is a better way to do things? 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. So I really think that we should think about other options first which solve the problem at a much more fundamental level before we start introducing new command line options. What do you think? Thanks! cheers, josch signature.asc Description: signature
Bug#904968: sbuild: please add --no-source-only-changes option
Hello Johannes, On Mon 30 Jul 2018 at 06:37AM +0200, Johannes Schauer wrote: > is there any reason why dgit does not set the SBUILD_CONFIG environment > variable to either an empty value or to a config file that lets sbuild do > exactly what dgit expects it to do? We are not trying to be a full wrapper for sbuild. The user's config should be allowed to take effect. For example before an upload I type % dgit sbuild --run-autopkgtest --run-piuparts but autopkgtest and piuparts will not work without my .sbuildrc. Generating a _source.changes is the only option that we must turn off. -- Sean Whitton signature.asc Description: PGP signature
Bug#904968: sbuild: please add --no-source-only-changes option
Hi, Quoting Sean Whitton (2018-07-30 05:58:47) > Please provide a command line option to override the sbuildrc > configuration key SOURCE_ONLY_CHANGES. I suggest > --no-source-only-changes. > > When dgit invokes sbuild it generates the _source.changes itself, and > needs to prevent sbuild from overwriting it, and prevent the situation > where there are two _sources.changes floating around. is there any reason why dgit does not set the SBUILD_CONFIG environment variable to either an empty value or to a config file that lets sbuild do exactly what dgit expects it to do? Thanks! cheers, josch signature.asc Description: signature
Bug#904968: sbuild: please add --no-source-only-changes option
Package: sbuild Version: 0.77.0-4 Tags: upstream X-debbugs-cc: ijack...@chiark.greenend.org.uk Dear maintainer, Please provide a command line option to override the sbuildrc configuration key SOURCE_ONLY_CHANGES. I suggest --no-source-only-changes. When dgit invokes sbuild it generates the _source.changes itself, and needs to prevent sbuild from overwriting it, and prevent the situation where there are two _sources.changes floating around. -- Sean Whitton signature.asc Description: PGP signature
