From: Manoj Srivastava <[EMAIL PROTECTED] (va, manoj)> > On Fri, 8 Jul 2005 19:08:38 -0700 (PDT), Elliott Mitchell <[EMAIL PROTECTED]> > said: > > > Besides the obvious "me too", it might also be nice for DEB_DEST be > > overridden either by the command line or environment variable. > > This is not high on my list. The use case presented (needing > to have multiple compilations at the same time) is better addressed > by using cp -lr to create a link farm; this allows one to have > different patches applied to different machines without impacting > space usage a whole lot (doing separate build directories, on the > other hand, does not allow different machines to have different > patches, which is a show stopper for me).
Are there installations that are large enough that they want to patch on a per-machine basis? For midsize installations, simply turning off patch effects via config options is sufficient. OTOH for the hardlink tree, being able to override the value of DEB_DEST is quite valuable. (simplest is to have 'rules' pick it up from the environment) > Secondly, it is not clear how third party modules, and even > packaging the kernel-image, would be impacted by separate build > directories, and the number of variants is large enough to make this > excercise non-trivial, and at a time when the kernel-package > internals are going to be re-written for modularity, this is not > something that is high on the list, given that simple, and better, > workarounds for the sue case exist. Don't the kernel scripts themselves take care of most of the work for third party modules? -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | [EMAIL PROTECTED] PGP 8881EF59 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]