On Fri, 2012-01-27 at 08:29:53 +0100, Raphael Hertzog wrote: > On Fri, 27 Jan 2012, Guillem Jover wrote: > > 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. > > Sure. But a directory to use would certainly be an option and not a > command...
Right, but the pathname is (optionally) passed as part of the command, not as an option, in addition it (almost) always gets passed, at least from source packages. So it would still go against the principle that environment vars do not override command line options, because the caller explicitly passed a pathname not a filename for the deb, an output dir would override that. So it would only be ok on invokations w/o an explicit pathname argument, or I guess just a filename. For other cases consider we'd either have to strip any directory components from the pathname given on the command line or the user would need to pass an output dir one level down the path so that the ../ would get neutralized. > > 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. > > Yes. To make this more explicit, this is something that has crossed my mind several times, to look into a new design that would move things outside the packaging, so that for example dpkg-deb would be done externally. For example the RPM source format has some of these properties, but has other problems of its own. thanks, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
