* Patch: 3.1.6-bart-7: Another rlimit @ 1999-10-19 5:22 Bart Schaefer 1999-10-19 6:13 ` PATCH: " Bart Schaefer 0 siblings, 1 reply; 17+ messages in thread From: Bart Schaefer @ 1999-10-19 5:22 UTC (permalink / raw) To: zsh-workers Albert Chin reports that IRIX 6.5 has RLIMIT_PTHREAD The maximum number of threads (pthreads(5)) that a process may create. Functions that attempt to create new threads beyond this limit will fail with the error EAGAIN. Index: Doc/Zsh/builtins.yo =================================================================== @@ -521,6 +521,7 @@ sitem(tt(descriptors))(Maximum value for a file descriptor.) sitem(tt(filesize))(Largest single file allowed.) sitem(tt(maxproc))(Maximum number of processes.) +sitem(tt(maxpthreads))(Maximum number of threads per process.) sitem(tt(memorylocked))(Maximum amount of memory locked in RAM.) sitem(tt(memoryuse))(Maximum resident set size.) sitem(tt(resident))(Maximum resident set size.) Index: Src/Builtins/rlimits.awk =================================================================== @@ -33,6 +33,7 @@ if (limnam == "NOFILE") { msg[limnum] = "Ndescriptors" } if (limnam == "NPROC") { msg[limnum] = "Nmaxproc" } if (limnam == "OFILE") { msg[limnum] = "Ndescriptors" } + if (limnam == "PTHREAD") { msg[limnum] = "Nmaxpthreads" } if (limnam == "RSS") { msg[limnum] = "Mresident" } if (limnam == "SBSIZE") { msg[limnum] = "Msockbufsize" } if (limnam == "STACK") { msg[limnum] = "Mstacksize" } -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* PATCH: Re: Patch: 3.1.6-bart-7: Another rlimit 1999-10-19 5:22 Patch: 3.1.6-bart-7: Another rlimit Bart Schaefer @ 1999-10-19 6:13 ` Bart Schaefer 1999-10-20 20:17 ` Zefram 1999-10-24 0:45 ` 3.0 DESTDIR Clint Adams 0 siblings, 2 replies; 17+ messages in thread From: Bart Schaefer @ 1999-10-19 6:13 UTC (permalink / raw) To: zsh-workers On Oct 19, 5:22am, Bart Schaefer wrote: } Subject: Patch: 3.1.6-bart-7: Another rlimit } } RLIMIT_PTHREAD The maximum number of threads (pthreads(5)) The "ulimit -a" command should report this; same for "sockbufsize". Index: Src/Builtins/rlimits.c =================================================================== @@ -232,6 +232,20 @@ limit /= 1024; break; # endif /* RLIMIT_AIO_MEM */ +# ifdef RLIMIT_SBSIZE + case RLIMIT_SBSIZE: + if (head) + printf("socket buffer size (kb) "); + if (limit != RLIM_INFINITY) + limit /= 1024; + break; +# endif /* RLIMIT_SBSIZE */ +# ifdef RLIMIT_PTHREAD + case RLIMIT_PTHREAD: + if (head) + printf("threads per process "); + break; +# endif /* RLIMIT_PTHREAD */ } /* display the limit */ if (limit == RLIM_INFINITY) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: Re: Patch: 3.1.6-bart-7: Another rlimit 1999-10-19 6:13 ` PATCH: " Bart Schaefer @ 1999-10-20 20:17 ` Zefram 1999-10-21 1:53 ` Bart Schaefer 1999-10-24 0:45 ` 3.0 DESTDIR Clint Adams 1 sibling, 1 reply; 17+ messages in thread From: Zefram @ 1999-10-20 20:17 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers Bart Schaefer wrote: >} RLIMIT_PTHREAD The maximum number of threads (pthreads(5)) > >The "ulimit -a" command should report this; same for "sockbufsize". Should it? There are several limits that ulimit can't set; I intuitively feel that it should be reporting only the same set of limits that it can set. Btw, the name "maxpthreads" seems sub-optimal -- what's wrong with "maxthreads"? -zefram ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: Re: Patch: 3.1.6-bart-7: Another rlimit 1999-10-20 20:17 ` Zefram @ 1999-10-21 1:53 ` Bart Schaefer 0 siblings, 0 replies; 17+ messages in thread From: Bart Schaefer @ 1999-10-21 1:53 UTC (permalink / raw) To: Zefram; +Cc: zsh-workers On Oct 20, 9:17pm, Zefram wrote: } Subject: Re: PATCH: Re: Patch: 3.1.6-bart-7: Another rlimit } } Bart Schaefer wrote: } >} RLIMIT_PTHREAD The maximum number of threads (pthreads(5)) } > } >The "ulimit -a" command should report this; same for "sockbufsize". } } Should it? There are several limits that ulimit can't set; I intuitively } feel that it should be reporting only the same set of limits that it } can set. I wondered about that, but it was already reporting several limits that it can't set (address space, cached threads, AIO operations and memory) so there didn't seem to be any point in leaving out these two. } Btw, the name "maxpthreads" seems sub-optimal -- what's wrong with } "maxthreads"? I went back and forth on that. Eventually I left in the "p" because there are other threading systems than POSIX threads and it's conceivable that a system might have limits for more than one. E.g., is the "cachedthreads" limit related to POSIX threads? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* 3.0 DESTDIR 1999-10-19 6:13 ` PATCH: " Bart Schaefer 1999-10-20 20:17 ` Zefram @ 1999-10-24 0:45 ` Clint Adams 1999-10-24 1:55 ` Bart Schaefer 1 sibling, 1 reply; 17+ messages in thread From: Clint Adams @ 1999-10-24 0:45 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers Bart, please backport the DESTDIR stuff for inclusion in 3.0.8. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: 3.0 DESTDIR 1999-10-24 0:45 ` 3.0 DESTDIR Clint Adams @ 1999-10-24 1:55 ` Bart Schaefer 1999-10-24 5:05 ` Clint Adams 0 siblings, 1 reply; 17+ messages in thread From: Bart Schaefer @ 1999-10-24 1:55 UTC (permalink / raw) To: Clint Adams; +Cc: zsh-workers On Oct 23, 8:45pm, Clint Adams wrote: } Subject: 3.0 DESTDIR } } Bart, please backport the DESTDIR stuff for inclusion in 3.0.8. I'll consider it, but in retrospect I'm doubtful that it should have been included in 3.1 in the first place. (Yes, I know I argued in favor at the time.) However, I now can't see how make DESTDIR=/foo/bar/baz install differs in end result from make make prefix=/foo/bar/baz/usr/local install provided that the same options were passed to "configure" in each case. It just seems we've scattered references to $DESTDIR in a whole lot of files (introducing several bugs that had to be fixed later along the way) without actually achieving anything new. If you can show me something substantially different that DESTDIR is the best way to handle, I might swing back the other way again. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: 3.0 DESTDIR 1999-10-24 1:55 ` Bart Schaefer @ 1999-10-24 5:05 ` Clint Adams 1999-10-24 6:20 ` Bart Schaefer 0 siblings, 1 reply; 17+ messages in thread From: Clint Adams @ 1999-10-24 5:05 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers > However, I now can't see how > > make DESTDIR=/foo/bar/baz install > > differs in end result from > > make > make prefix=/foo/bar/baz/usr/local install Well, I can answer that since my surprise at those two not being effectively the same is precisely the reason I wanted DESTDIR in the first place: (illustration using bart7) % ./configure --prefix=/usr [output elided] % make [output elided] % make prefix=/tmp/zshtest/usr install [output elided] % strings /tmp/zshtest/usr/bin/zsh | grep tmp /tmp/zshtest/usr/share/zsh/functions /tmp/zshtest/usr/lib/zsh/3.1.6-bart-7 /tmp/zsh /tmp/zsh /var/log/wtmp /var/run/utmp % /tmp/zshtest/usr/bin/zsh -f % echo $fpath /tmp/zshtest/usr/share/zsh/functions The functions are there, as are the modules, but if you were to chroot to /tmp/zshtest, you'd be screwed. DESTDIR provides a safe way to guarantee against this sort of thing because nothing depends on it but the install, whereas prefix is used to generate fndir and libdir, which are then used in the somewhat unexpected recompile and relink during the install target. I hope that that was coherent. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: 3.0 DESTDIR 1999-10-24 5:05 ` Clint Adams @ 1999-10-24 6:20 ` Bart Schaefer 1999-10-24 14:30 ` Clint Adams 0 siblings, 1 reply; 17+ messages in thread From: Bart Schaefer @ 1999-10-24 6:20 UTC (permalink / raw) To: Clint Adams; +Cc: zsh-workers On Oct 24, 1:05am, Clint Adams wrote: } Subject: Re: 3.0 DESTDIR } } > make DESTDIR=/foo/bar/baz install } > } > differs in end result from } > } > make } > make prefix=/foo/bar/baz/usr/local install } } Well, I can answer that since my surprise at those two not being effectively } the same is precisely the reason I wanted DESTDIR in the first place: } (illustration using bart7) } } % strings /tmp/zshtest/usr/bin/zsh | grep tmp } /tmp/zshtest/usr/share/zsh/functions } /tmp/zshtest/usr/lib/zsh/3.1.6-bart-7 Ah, yes, I had noticed that recompile, too, but: (1) that doesn't apply to 3.0.x, because it doesn't compile any of those strings into the binary, so you still haven't given a reason to have the DESTDIR patch in that version; and (2) that recompile is a bug in the 3.1.6 build process which I think we ought to fix whether or not DESTDIR is also available; and (3) DESTDIR isn't sufficient anyway, because simply prefixing the entire path from the root forces you to install into a precise mirror tree of the install hierarchy. It turns out that in one of the cases where I thought DESTDIR would be useful, it actually is not; because what I want is to change /usr/local/* into /usr/local/stow/zsh/*, that is, insert a new hierarchy _below_ ${prefix} rather than above. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: 3.0 DESTDIR 1999-10-24 6:20 ` Bart Schaefer @ 1999-10-24 14:30 ` Clint Adams 1999-10-24 14:51 ` Bruce Stephens 1999-10-24 17:58 ` PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) Bart Schaefer 0 siblings, 2 replies; 17+ messages in thread From: Clint Adams @ 1999-10-24 14:30 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers > (1) that doesn't apply to 3.0.x, because it doesn't compile any of those > strings into the binary, so you still haven't given a reason to have the > DESTDIR patch in that version; and Fair enough. I withdraw the request. > (2) that recompile is a bug in the 3.1.6 build process which I think we > ought to fix whether or not DESTDIR is also available; and Agreed. > (3) DESTDIR isn't sufficient anyway, because simply prefixing the entire > path from the root forces you to install into a precise mirror tree of > the install hierarchy. It turns out that in one of the cases where I > thought DESTDIR would be useful, it actually is not; because what I want > is to change /usr/local/* into /usr/local/stow/zsh/*, that is, insert a > new hierarchy _below_ ${prefix} rather than above. Yes, DESTDIR is useful for automated package building and bootstrapping a chrooted environment, but not what you describe. However, I'm not sure why you would want to install files into /usr/local/stow that believe their functions/modules are going to be in /usr/local. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: 3.0 DESTDIR 1999-10-24 14:30 ` Clint Adams @ 1999-10-24 14:51 ` Bruce Stephens 1999-10-27 2:17 ` Clint Adams 1999-10-24 17:58 ` PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) Bart Schaefer 1 sibling, 1 reply; 17+ messages in thread From: Bruce Stephens @ 1999-10-24 14:51 UTC (permalink / raw) To: zsh-workers Clint Adams <schizo@debian.org> writes: > Yes, DESTDIR is useful for automated package building and bootstrapping > a chrooted environment, but not what you describe. Can't you use "make install prefix=..." there, too? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: 3.0 DESTDIR 1999-10-24 14:51 ` Bruce Stephens @ 1999-10-27 2:17 ` Clint Adams 0 siblings, 0 replies; 17+ messages in thread From: Clint Adams @ 1999-10-27 2:17 UTC (permalink / raw) To: Bruce Stephens; +Cc: zsh-workers > Can't you use "make install prefix=..." there, too? In 3.0 you can. No in 3.1, because the function and modules directories are reset and hardcoded to the absolute paths. Many other programs do this and don't support DESTDIR, and they are an annoyance. perl for instance. GNU awk. texinfo. texutils.. ^ permalink raw reply [flat|nested] 17+ messages in thread
* PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) 1999-10-24 14:30 ` Clint Adams 1999-10-24 14:51 ` Bruce Stephens @ 1999-10-24 17:58 ` Bart Schaefer 1999-10-24 21:04 ` Zefram 1999-10-28 1:58 ` Juergen A. Erhard 1 sibling, 2 replies; 17+ messages in thread From: Bart Schaefer @ 1999-10-24 17:58 UTC (permalink / raw) To: Clint Adams, zsh-workers This is a whole lot of verbiage ending in a very short patch. On Oct 24, 10:30am, Clint Adams wrote: } Subject: Re: 3.0 DESTDIR } } > (2) that recompile is a bug in the 3.1.6 build process which I think we } > ought to fix whether or not DESTDIR is also available; and } } Agreed. The issue appears to be that the instructions for building zshpaths.h are considered to be a module definition task (they're in zsh.mdd) rather than a configuration task. So they don't get pasted into a Makefile until the "make -f Makemod" gets run, and hence are compile-time rather than config- time substituted. This is compounded by dependence on $(VERSION), which is a make-time rather than config-time value as well. However, I think the following patch will do the right things: Before the patch, the target zshpaths.h depends on FORCE, and then the rule avoids touching the file if it hasn't changed. The patch simply replaces FORCE with a dependency on the .mk files that define the variables that become part of the strings in zshpaths.h; so if you re-configure, or "cvs update" to a newer version of the sources, zshpaths.h will get remade. This means that "make MODDIR=/some/new/path fndir=/some/other/new/path" does not recompile zsh, but "make ... install" still installs the modules and functions in the new $(MODDIR) and $(fndir) locations. I'm now considering backing out the $DESTDIR stuff, because with this patch you can do this kind of thing (which works in 3.0.7 as well, by the way): configure --prefix='${INSTROOT}/usr/local' make make INSTROOT=/tmp/zshtest install } However, I'm not sure why you would want to install files into } /usr/local/stow that believe their functions/modules are going to be } in /usr/local. There's a GNU package called "stow" (based on something called "depot" that originated at CMU). It's a package-installation utility designed for use in shared-filesystem environments. Rather than copy the files from the package directly into place the way an RPM or Debian package does, it expects to find the packages in subdirectories of a directory (usually also named "stow") whose *parent* directory is the equivalent of the ${prefix}. It constructs relative symlinks pointing into each package's tree in the corresponding subdirs of the parent directory. E.g., /usr/local/bin/zsh -> ../stow/zsh/bin/zsh after "stow zsh". Thus the same "stow" directory can be NFS mounted on multiple machines, and each of those machines can selectively install/uninstall packages without consuming additional disk space. This doesn't work for every package, because some things get security indigestion if they find a symlink in their execution path; but it's great for things like elisp libraries and zsh functions that are architecture-independent and can usually be updated independently of the interpreters that run them. Here's the patch. Index: Src/zsh.mdd =================================================================== @@ -12,6 +12,8 @@ prototypes.h hashtable.h ztype.h" :<<\Make +@CONFIG_MK@ + signames.c: signames1.awk signames2.awk ../config.h @SIGNAL_H@ $(AWK) -f $(sdir)/signames1.awk @SIGNAL_H@ >sigtmp.c $(CPP) sigtmp.c >sigtmp.out @@ -28,7 +30,7 @@ version.h: $(sdir_top)/Config/version.mk echo '#define ZSH_VERSION "'$(VERSION)'"' > $@ -zshpaths.h: FORCE Makemod +zshpaths.h: Makemod $(CONFIG_INCS) @echo '#define MODULE_DIR "'$(MODDIR)'"' > zshpaths.h.tmp @if test x$(fndir) != xno; then \ echo '#define FPATH_DIR "'$(fndir)'"' >> zshpaths.h.tmp; \ -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) 1999-10-24 17:58 ` PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) Bart Schaefer @ 1999-10-24 21:04 ` Zefram 1999-10-24 21:55 ` Bart Schaefer 1999-10-24 21:57 ` Bart Schaefer 1999-10-28 1:58 ` Juergen A. Erhard 1 sibling, 2 replies; 17+ messages in thread From: Zefram @ 1999-10-24 21:04 UTC (permalink / raw) To: Bart Schaefer; +Cc: schizo, zsh-workers Bart Schaefer wrote: >This means that "make MODDIR=/some/new/path fndir=/some/other/new/path" >does not recompile zsh, I intentionally wrote that code so that that *would* cause a recompile. make MODDIR=foo guarantees to build a zsh which has the module directory specified. After your patch, changing MODDIR for make results in a zsh with indeterminate module directory. You would require a "make clean" to reliably change the module directory, when in reality only a couple of files need to be rebuilt. (I'm operating under a more general principle that the final result of make should be the same regardless of files already built; make's job is simply to minimise the amount that gets rebuilt, reusing a partial build if possible.) Btw, my view is that giving different parameters to "make install" from those one gave to "make" is a bad practice, but if it is to be supported then the parameters from "make install" must take precedence. After all, those are the parameters that will take effect if anything changes and gets rebuilt during the "make install". All of this is a matter of "least surprise", too. >I'm now considering backing out the $DESTDIR stuff, because with this patch >you can do this kind of thing (which works in 3.0.7 as well, by the way): > > configure --prefix='${INSTROOT}/usr/local' > make > make INSTROOT=/tmp/zshtest install Surely you're joking, Mr Schaefer. OK, that's a nice hack, but DESTDIR is a whole lot clearer. Let's keep configured pathnames and install paths properly distinct. -zefram ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) 1999-10-24 21:04 ` Zefram @ 1999-10-24 21:55 ` Bart Schaefer 1999-10-24 21:57 ` Bart Schaefer 1 sibling, 0 replies; 17+ messages in thread From: Bart Schaefer @ 1999-10-24 21:55 UTC (permalink / raw) To: Zefram; +Cc: zsh-workers On Oct 24, 10:04pm, Zefram wrote: } Subject: Re: PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) } } Bart Schaefer wrote: } >This means that "make MODDIR=/some/new/path fndir=/some/other/new/path" } >does not recompile zsh, } } I intentionally wrote that code so that that *would* cause a recompile. I understand that. } Btw, my view is that giving different parameters to "make install" } from those one gave to "make" is a bad practice, but if it is to be } supported then the parameters from "make install" must take precedence. Unfortunately, it's my understanding that the GNU-accepted practice for changing the install location of software that is under autoconf/configure control is exactly what my patch permits. Of course we're not actually GNU-ware (thank goodness) so we can ignore that if we choose, but it's been causing me to have to copy things into the install directories by hand for as long as I've been building 3.1.x. Did you read my description of the "stow" utility? If "make install" alters the binary, how does one produce a correctly-configured binary that can be managed by such a utility? } After all, those are the parameters that will take effect if anything } changes and gets rebuilt during the "make install". Yes, that's true. It's up to a package installer to do the steps in the right order: That is, never "make install" without first doing "make". } Let's keep configured pathnames and install paths properly distinct. Exactly. Paths that are hardwired into compiled components should be those specified at configure time, not those specified at "make" time. That's why they call it "configure". Unfortunately, without a much more significant rewrite of the module build system, we can't achieve that. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) 1999-10-24 21:04 ` Zefram 1999-10-24 21:55 ` Bart Schaefer @ 1999-10-24 21:57 ` Bart Schaefer 1 sibling, 0 replies; 17+ messages in thread From: Bart Schaefer @ 1999-10-24 21:57 UTC (permalink / raw) To: Zefram; +Cc: zsh-workers On Oct 24, 10:04pm, Zefram wrote: } Subject: Re: PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) } } [...] After your patch, changing MODDIR for make results in a zsh } with indeterminate module directory. You would require a "make clean" } to reliably change the module directory, when in reality only a couple of } files need to be rebuilt. Incidentally, "make clean" is NOT required if you rerun "configure" instead. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) 1999-10-24 17:58 ` PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) Bart Schaefer 1999-10-24 21:04 ` Zefram @ 1999-10-28 1:58 ` Juergen A. Erhard 1999-10-28 3:31 ` Bart Schaefer 1 sibling, 1 reply; 17+ messages in thread From: Juergen A. Erhard @ 1999-10-28 1:58 UTC (permalink / raw) To: schaefer; +Cc: schizo, zsh-workers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Bart" == Bart Schaefer <schaefer@candle.brasslantern.com> writes: [SNIP] A few minor (and probably totally unimportant ;-) corrections: Bart> There's a GNU package called "stow" (based on something Bart> called "depot" that originated at CMU). From stow.texi: Stow was inspired by Carnegie Mellon's Depot program, [...] It is definitely not based on it (in the narrower sense). Bart> It's a package-installation utility designed for use in Bart> shared-filesystem environments. Also according to stow.texi, it's for keeping files from different packages apart, nothing more, nothing less. So, when you have "a2p.1" in "/usr/local/man/man1", you can easily find out which package this file is from. Of course you can *use* it for what you describe ;-) (And maybe that was depot's intended use). [SNIP] Bye, J PS: It's good to see support for stow... I use it for everything under /usr/local. Aaaand building Debian (and I guess RH) packages poses some of the same problems: you need to `install' into a different place than the one the package later has to run in. - -- Jürgen A. Erhard eMail: jae@ilk.de phone: (GERMANY) 0721 27326 MARS: http://members.tripod.com/~Juergen_Erhard/mars_index.html GNUstep - Free OPENSTEP (http://www.gnustep.org) "No matter how cynical I get, I can't keep up." -- Bruce Schneier -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjgXrckACgkQN0B+CS56qs1ijQCfWK6UjW7RC6nswVX2ONmKKz9f 9KMAn2+nDEsej0AohXyr6RigDWsOGlvP =Gi++ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) 1999-10-28 1:58 ` Juergen A. Erhard @ 1999-10-28 3:31 ` Bart Schaefer 0 siblings, 0 replies; 17+ messages in thread From: Bart Schaefer @ 1999-10-28 3:31 UTC (permalink / raw) To: Juergen A. Erhard; +Cc: zsh-workers On Oct 28, 3:58am, Juergen A. Erhard wrote: } Subject: Re: PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) } } Also according to stow.texi, it's for keeping files from different } packages apart, nothing more, nothing less. [...] } } Of course you can *use* it for what you describe ;-) (And maybe that } was depot's intended use). I find this amusing, considering that I've sat no more than twelve feet from Bob Glickstein almost every working day for the past seven years. Yes, I know what he wrote in stow.texi, but trust me when I say that I also know exactly what stow's author uses stow for! As for whether it's "based on" depot ... the perl script was "depot.pl" for the first four years of its life, right up until Bob decided it had to be called something else if he was going to release it through FSF. However, this now has absolutely nothing to do with zsh, so to make this at least slightly topical: I'll be offline from tomorrow through the weekend, so with the exception of a couple of messages tonight I probably won't be answering any zsh mail until Tuesday. Don't pile the patches too deep in the meantime ... -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~1999-10-28 3:32 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-10-19 5:22 Patch: 3.1.6-bart-7: Another rlimit Bart Schaefer 1999-10-19 6:13 ` PATCH: " Bart Schaefer 1999-10-20 20:17 ` Zefram 1999-10-21 1:53 ` Bart Schaefer 1999-10-24 0:45 ` 3.0 DESTDIR Clint Adams 1999-10-24 1:55 ` Bart Schaefer 1999-10-24 5:05 ` Clint Adams 1999-10-24 6:20 ` Bart Schaefer 1999-10-24 14:30 ` Clint Adams 1999-10-24 14:51 ` Bruce Stephens 1999-10-27 2:17 ` Clint Adams 1999-10-24 17:58 ` PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) Bart Schaefer 1999-10-24 21:04 ` Zefram 1999-10-24 21:55 ` Bart Schaefer 1999-10-24 21:57 ` Bart Schaefer 1999-10-28 1:58 ` Juergen A. Erhard 1999-10-28 3:31 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).