On Wed, May 30, 2001 at 01:18:57PM +0200, Marc Espie wrote:
> Sigh... why do you guys always have to invent new terminology, and point
> out you didn't use our code ?  

I'm the one who implemented these changes, and I considered that the
name "FAKE" was not descriptive enough for the action that was taking
place.  To me, "FAKE" means "counterfeit", "not genuine", "unreal". 
Obviously, I don't know what you mean by "FAKE", but if it doesn't
describe a function accurately, why ever should I use it?  If you'd
called it "Basil", "sea bass" or "300 yards of asphalt", I'd still
have changed the name.

I wanted to attribute credit where it's due, and so I acknowledged the
source of the method for doing staged installations.  Yes, it's a neat
idea, and I said so.  However, I also wanted to make sure that people
were aware of where the boundaries were, and what was attributable to
whom.

> I thought the war was mostly over.

I wasn't even aware I was fighting a war - my apologies. Whose side
am I on?
 
> Two or three points:
> 
> - DESTDIR is normally used for this kind of stunt. There's more to FAKE
> than meet the eyes. In reality, recent GNU stuff, for instance, heeds
> DESTDIR. Which is why the PREFIX='$${STAGE_PREFIX}${PREFIX}' is only used
> for ports that need it.  In theory, imake stuff knows about DESTDIR as well. 
> A few broken Imakefile leave a space in the wrong position, and need fixing
> there.  Consider using DESTDIR. In many cases where it's supported,
> configuring using PREFIX='$${STAGE_PREFIX}${PREFIX}' does not work.
> For instance, teTeX needs some further magic, because it evals its prefix
> in such a way that this just doesn't work.
>
> - most Makefile.in that heed DESTDIR actually have
> DESTDIR=
> in the Makefile.in.
> 
> That's so that you can (should) override DESTDIR in flags you pass to
> make during install. That's the purpose of FAKE_FLAGS in OpenBSD.
> Some AFS stuff uses similar conventions (INSTALL_TOP instead of DESTDIR
> if memory serves).
>
> - if I trust your cvs, you still haven't changed your make to pass
> variables set on the command line to submakes through MAKEFLAGS.
> It's your choice, but you're making it extra tough for handling stage
> installs. Especially since passing MAKEFLAGS to submakes is a POSIX
> feature, so whatever tweaks you will need to do to get fake installs to
> work with recursive makefiles WON'T be taken back by software authors.
> The code is trivial. You probably have a few tweaks to make throughout your
> source tree to make it work, but believe me, it's worth it.

Thanks for the information.

> - completely dynamic packing-lists may not be such a good idea. It has been
> technically feasible in OpenBSD as well ever since we got fake, and we
> haven't used it. Why ?  well, it's good being able to compute the actual 
> packing-lists without having to build the whole package. Stuff like package
> conflicts come to mind... 

I think you are underestimating the utility value of dynamic inventories,
but obviously you know best.
 
> As you said, updating packing-lists is a large part of the chore of
> updating packages, but there ARE good reasons for that. It is incredibly
> easy to miss problems with automatic packing-lists. Problems that become
> glaringly obvious when you check what changes.

We've just gone through a major scrutiny of all our packages, such that
all "leftovers" from a bulk build have been eradicated. Frankly, I don't
want to do it again. We'll use dynamic inventories for the packages that
can use them effectively, and we'll retain static PLISTs for those that
can't. When all packages have been tried, we'll re-evaluate the situation,
and see if we need to retain static PLISTs.

> As far as faking stuff goes, we have less than 20 ports left unfaked in the
> OpenBSD tree... and they've mostly been left that way because they're not
> that useful.

As far as staged installations go, we have 2145+ packages that we
still have to evaluate, on numerous different platforms.

Regards,
Alistair