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
