Subject: Re: make package
To: Lubomir Sedlacik <>
From: Alistair Crooks <>
List: tech-pkg
Date: 06/29/2002 00:11:57
On Thu, Jun 27, 2002 at 08:02:23PM +0200, Lubomir Sedlacik wrote:
> On Thu, Jun 27, 2002 at 05:52:18PM +0200, Hubert Feyrer wrote:
> > On Thu, 27 Jun 2002, Marton Fabo wrote:
> > >
> > > Hmmm, hmmm. Well, that's what I meant, now I understand. Actually,
> > > don't you guys see this as a place for enhancement in the package
> > > system? It's quite shame that I can compile a new version, so I have
> > > the binaries, but I cannot tar them up without having to install
> > > them on the system... And
> > 
> > Well, that's a known problem, and I *think* someone's working on that.
> > The problem is at least known, and there was some idea-tossing about
> > solving it.
> something like OpenBSD ports fake-root feature would be very nice to
> have.  i think it's more sane way of building packages because your
> system is keeping intact to the point when you have binary package ready
> and it's installed the only way--using pkg_add--regardless on the fact
> whether you compile it yourself or use binary packages, and don't place
> files to your system in 'make install' stage, which means that you need
> to remove your old package before 'make install' is executed..

Actually, Stoned Elipot and I spent the best part of a week looking
at this, and implementing three methods of doing it. Those methods

1. destdir already in the package (as used in Debian, OpenBSD's FAKE,
X11 packages with xmkmf, and others)

2. custom scripts invoked at install time as wrappers around install,
gzip, etc (to allow "install wibble ${PREFIX}/bin/wibble" to be caught
and the ${PREFIX}/bin/wibble modified to ${DESTDIR}${PREFIX}/bin/wibble,

3. GNU exec_prefix different from prefix, as found in most auto* tools

The best method for each package had to be identified and implemented.
Often it was not the most obvious choice that worked best.

At the end of that week, we had done about 70 packages, the most notable
omission being Perl, which is just difficult to work with. Each package
had to be investigated by hand, and the correct method identified and
implemented. We both considered that it was too much pain for too little

When we've emerged from 1.6, we'll be adding another branch called pkgviews,
which is a more complete answer to the problem.