On Thu, 2012-01-26 at 08:29:51 +0100, Raphael Hertzog wrote: > On Wed, 25 Jan 2012, Don Armstrong wrote: > > On Thu, 26 Jan 2012, Guillem Jover wrote: > > > I implemented this, but then realized that it cannot be done > > > cleanly, as dpkg-deb is called from inside debian/rules and will > > > always place the binary packages under «..», so dpkg-buildpackage > > > would need to move the files itself afterwards. While that could be > > > done, it might not avoid the problem you refer to. > > > > Hrm; true. I actually wanted this primarily for debuild -S, but > > solving it for everything is probably necessary to solve it at all. > > Note that dpkg-source also creates files in the current directory and > expect to find files in the current directory (and dpkg-buildpackage > changes the current directory to ".." for the needs of dpkg-source). > > So if you change the current directory to your output directory, you also > have to do something to ensure that dpkg-source keeps on finding the orig > tarballs.
That's already handled by passing the sourcedir path to dpkg-source, the only change I had to do was to switch from relative paths to absolute ones in that case. > > The hack of sending an env option through to dpkg-deb is all kinds of > > ugly... > > Why would it be more ugly than dpkg-buildpackage -j setting > DEB_BUILD_OPTIONS="parallel"? Well DEB_BUILD_OPTIONS is a variable to be used by debian/rules directly if at all, which does not have other defined ways to pass options to it. Passing default options to dpkg-deb which is a sub-child, might be unreliable, depending on how the build process is handled, if there's environment cleanup from whoever ends up calling it, it does not necessarily need to be debian/rules for example, etc. > Of course, if there would be no constraints, I would not pick up an env > variable as preferred way to pass options but there are many tools > who are accepting options through the environment (think GZIP, > TAR_OPTIONS, etc.). I don't see why we couldn't do that. For starters all current invokations already use an explicit destination path for the deb. Environment variables are always used to set option defaults (not commands) that always get overridden by the command line, doing otherwise would be extremely confusing, and it's just ugly. In the end this comes down to the way or build system is currently designed, in that debian/rules is in charge of generating the resulting binary packages, which makes some global changes more difficult. regards, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
