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]
