Hi! On Tue, 2017-02-07 at 16:08:44 +0100, Sven Joachim wrote: > On 2017-02-07 14:41 +0100, Guillem Jover wrote: > > Well, yes and no. This was brought up on IRC by Ansgar when this new > > behavior showed up. The problem here is that you are building a source > > package by making a source-only build, disabling dependency checks and > > cleanup, which means the debian/files gets left behind. > > > > If what you want is to just create a source package then the correct > > thing to do IMO is to just run dpkg-source --build. > > But this source package cannot be uploaded then, because there is no > accompanying .changes file.
Sure, and I question the wisdom of doing a pure source-only upload w/o building the binaries at the same time. I think a preferable way is to use something like: $ dpkg-buildpackage --changes-option=-S or the equivalent sbuild/pbuilder incantation. > > Of course you might also need to run dpkg-source --before-build and > > --after-build. But not running clean and expecting things to stay > > clean seems a bit too much hopeful! :) > > The debian/files stays around even without the -d and -nc options, since > it is generated by dpkg-genchanges long after the source tree has been > cleaned. And dpkg-source --after-build does not clean it up. Right, sorry I see how my wording above was confusing, given that this issue has different effects. dpkg-buildpackage -S now generates the debian/files in the same way that other build types do. So there's arguably unexpected files generated, my position is that dpkg-buildpackage builds stuff, so it can generate those files. Then there's the possible problem of dpkg-source picking up those files and including them into the source package, when called with -nc. This could be fixed now by excluding this file, or in the future by excluding anything under the future proposed debian/.build/. But then building source w/o making sure the tree is clean is the problem here. On Tue, 2017-02-07 at 15:23:32 +0000, Thorsten Glaser wrote: > Guillem Jover dixit: > >Well, yes and no. This was brought up on IRC by Ansgar when this new > >behavior showed up. The problem here is that you are building a source > >package by making a source-only build, disabling dependency checks and > >cleanup, which means the debian/files gets left behind. > > I am disabling running 'debian/rules clean' (usually because the > packages have Build-Depends my workstation cannot fulfil), not > disabling dpkg cleaning up its own files _after_ the fact. > > Well, that was my intent anyway. Right, see my comment above. > >If what you want is to just create a source package then the correct > >thing to do IMO is to just run dpkg-source --build. Of course you > >might also need to run dpkg-source --before-build and --after-build. > > To remember all these is kinda dpkg-buildpackage’s job… In most cases yes. > >But not running clean and expecting things to stay clean seems a bit > >too much hopeful! :) > > Well, the option is documented as “no-pre-clean”. Maybe I’m also using > the wrong option, tell me… I generally use it only if building a source > package from a clean VCS tree (to throw into cowbuilder or do a source- > only upload) when “debian/rules clean” would error out (e.g. because it > use(s|d to use) dh-systemd which I cannot install on the host system). Hope my explanation above clarifies my confusing wording. I do think you are using the wrong tool for the job. If you are building from a clean tree and only want a source package, then just use dpkg-source, using dpkg-buildpackage is for builds/uploads. If you are preparing a source-only upload, I'd expect maintainers to build the binaries too. > In general, this works except for .pc/ and now debian/files. I don't think it's safe to expect dpkg-buildpackage to not generate stuff when it runs, TBH. > Might be useful to split them, maybe? -nc disables running d/r clean, > and a new option -nC also disables removing these? At least up to now «debian/rules clean» has been the responsible to remove for debian/files, changing that would a bit of an interface change. > >In principle for 1.19.x, I'd like to move all generated cruft to > >something like debian/.build/ or similar, which means we could add > >this to our VCS ignore rules and the above would "work". But otherwise > > I really prefer a lot to still have those files removed… I’d not > ignore them but grumble and remove them after dpkg-buildpackage > anyway, so please no. (Also, for git, ignored files generally stick > around when switching branches, which may be annoying later too.) See above. :) Thanks, Guillem
