On Sun, Jan 10, 1999 at 02:01:10PM +0000, Jules Bean wrote: > > Basically, the proposed modifications to support convenient > cross-compiling, and also to correctly support full architecture/os > strings, work on setting environment variables.
Yes, I like this. > Since we might expect > debian/rules files to only work properly when these variables are set, it > seems to make sense to provide a tool which correctly sets them. This is not correct. Invoking debian/rules without any environment variales set *will continue to work*. I was very carful that my proposed changes are fully backward compatible. Running new debian/rules script with old dpkg-dev, old debian/rules script with new dpkg-dev, or whatever strange situations you can come up with, it is always guaranteed that you get the old behaviour as default. > Furthermore, dpkg-buildpackage could (it seems to me) be easily turned > into that tool, since those tasks mesh well with dpkg-buildpackage's > current task. Manojs suggestion was that dpkg-buildpackage calls a seperate utility, and I agree. It can be done easily, and will satisfy everyone. > And I really don't think that typing 'dpkg-buildpackage -rfakeroot > --target binary' is all that much harder that 'fakeroot debian/rules > binary'. Well, yes. But it is important that we conveniently support both ways to do it. Wichert is right that it is important that nothing breaks if you use the old way. Manoj is right that you should be able to get the environment variables seperately from dpkg.buildpackage. You are right that dpkg-buildpackage can be improved by your proposed changes. Everyone should understand that it is indeed possible to support all these opinions. Erh, what are we argueing about? :) Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@ Marcus Brinkmann http://www.debian.org master.debian.org [EMAIL PROTECTED] for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
