Re: Use $DEB_BUILD_DIR rather than parent directory?
On Mon, Nov 20, 2000 at 10:37:03AM -0500, Eric Gillespie, Jr. wrote: I recently filed this wishlist bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=77153repeatmerged=yes) against dpkg-dev, and Wichert told me to take it up with policy, so here i am. I think it would be nice if the package-building tools would place files in $DEB_BUILD_DIR if it is set. If it isn't, they will continue their current behavior of dropping them in the parent directory. I think Wichert was wrong in this case. I don't think policy should be in charge of every minor feature of the toolkit, especially not optional features. This feature would have no effect unless you used it, and has no impact on interpackage relationships or other matters that policy is usually concerned with. The only *potential* problem I see is environment variable namespace pollution, and I hope we're not going to start voting on each and every varname the project uses! :-) cheers p.s. in the meantime, you might be able to work around the issue with some sort of NFS ad-hackery, or something similar. But it's ugly, and serious overkill of you're not already running NFS. # mkdir /deb/build/dir/mnt # mount -t nfs localhost:/path/to/source /deb/build/dir/mnt # cd /deb/build/dir/mnt # dpkg-buildpackage --options Or something along those lines... -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into | this .signature file.
Re: Use $DEB_BUILD_DIR rather than parent directory?
Previously Eric Gillespie, Jr. wrote: Does it? Why not just have dpkg override that final parameter with $DEB_BUILD_DIR? If someone sets this variable, they clearly want the files to go there and not '..'. No tool should try to second-guess the user. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Use $DEB_BUILD_DIR rather than parent directory?
On Wed, 22 Nov 2000 17:39:48 + (UTC), [EMAIL PROTECTED] (Wichert Akkerman) said: No tool should try to second-guess the user. Eh? It isn't. The user *told* dpkg to do this by setting the variable. -- Eric Gillespie, Jr. * [EMAIL PROTECTED] Software Developer Progeny Linux Systems - http://progeny.com
Re: Use $DEB_BUILD_DIR rather than parent directory?
Wichert == Wichert Akkerman [EMAIL PROTECTED] writes: Wichert Previously Eric Gillespie, Jr. wrote: Does it? Why not just have dpkg override that final parameter with $DEB_BUILD_DIR? If someone sets this variable, they clearly want the files to go there and not '..'. Wichert No tool should try to second-guess the user. Depends if you define user as the packager or the compiler. I am not sure if you are arguing for or against the change here. I would argue (although I don't feel strongly about this) that it should be the compilers[1] choice, and not the packagers choice. I would also argue that the packager shouldn't try to second guess the requirements of the compiler, because the packager has no way of knowing how the compiler likes to organise their source code. IMHO: This proposal is similar to others, eg. for the EDITOR environment variable, where it was decided that the end user should have the final say. The only difference here, is that patches to upstream code are not required. Note: [1] argghh! what should I call the compiler (person doing the compilation) so it doesn't get confused with the C compiler? -- Brian May [EMAIL PROTECTED]
Re: Use $DEB_BUILD_DIR rather than parent directory?
On 20-Nov-00, 09:37 (CST), Eric Gillespie, Jr. [EMAIL PROTECTED] wrote: I recently filed this wishlist bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=77153repeatmerged=yes) against dpkg-dev, and Wichert told me to take it up with policy, so here i am. I think it would be nice if the package-building tools would place files in $DEB_BUILD_DIR if it is set. If it isn't, they will continue their current behavior of dropping them in the parent directory. I, for one, would like this feature. I'm vastly confused about why it would be a policy issue, though. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Use $DEB_BUILD_DIR rather than parent directory?
Previously Steve Greenland wrote: I, for one, would like this feature. I'm vastly confused about why it would be a policy issue, though. because it means all debian/rules files need to be changed to replace dpkg --build debian/tmp .. with dpkg --build debian/tmp $(DEB_BUILD_DIR) Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Use $DEB_BUILD_DIR rather than parent directory?
On Mon, 20 Nov 2000 17:35:00 + (UTC), [EMAIL PROTECTED] (Wichert Akkerman) said: because it means all debian/rules files need to be changed to replace dpkg --build debian/tmp .. with dpkg --build debian/tmp $(DEB_BUILD_DIR) Does it? Why not just have dpkg override that final parameter with $DEB_BUILD_DIR? If someone sets this variable, they clearly want the files to go there and not '..'. -- Eric Gillespie, Jr. * [EMAIL PROTECTED] Software Developer Progeny Linux Systems - http://progeny.com
Re: Use $DEB_BUILD_DIR rather than parent directory?
On 20-Nov-00, 11:32 (CST), Wichert Akkerman [EMAIL PROTECTED] wrote:
Previously Steve Greenland wrote:
I, for one, would like this feature. I'm vastly confused about why it
would be a policy issue, though.
because it means all debian/rules files need to be changed to replace
dpkg --build debian/tmp ..
with
dpkg --build debian/tmp $(DEB_BUILD_DIR)
Or just modify dpkg (or actually dpkg-deb, I guess) could be modified
to look for the environment variable DEB_BUILD_DIR and use it if it
was defined, requiring no changes at all to the debian/rules files. I
assumed that was the whole point of the proposal. Since dpkg-deb already
supports an alternative target directory, I can't believe that this is
all that difficult. In fact, here's a (briefly) tested patch:
--- dpkg-1.7.1.1/dpkg-deb/build.c Tue Aug 22 16:21:59 2000
+++ dpkg-1.7.1.2/dpkg-deb/build.c Mon Nov 20 12:30:29 2000
@@ -175,13 +175,13 @@
subdir= 0;
if ((debar= *argv++) !=0) {
if (*argv) badusage(_(--build takes at most two arguments));
-if (debar) {
- if (stat(debar,debarstab)) {
-if (errno != ENOENT)
- ohshite(_(unable to check for existence of archive
`%.250s'),debar);
- } else if (S_ISDIR(debarstab.st_mode)) {
-subdir= 1;
- }
+ }
+ if (debar || ((debar = getenv(DEB_BUILD_DIR)) != NULL)) {
+if (stat(debar,debarstab)) {
+ if (errno != ENOENT)
+ohshite(_(unable to check for existence of archive `%.250s'),debar);
+} else if (S_ISDIR(debarstab.st_mode)) {
+ subdir= 1;
}
} else {
m= m_malloc(strlen(directory) + sizeof(DEBEXT));
Steve
--
Steve Greenland [EMAIL PROTECTED]
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
pgp1unJoKrDqD.pgp
Description: PGP signature
