Re: Preserving binary packages

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Mon, Nov 10, 2014 at 09:19:03AM +0900, OBATA Akio wrote:
> On Mon, 10 Nov 2014 03:53:47 +0900, Alistair Crooks <agc%pkgsrc.org@localhost> wrote:
> 
> >In May 2013, the default of preserving binary packages at package install
> >time was changed, from yes to no.  The change was made to stop
> >overwriting existing binary packages (although the "replace" example
> >given surprises me, as the existing binary package is placed in the
> >WRKDIR, not in the packages dir).
> >
> >	PatchSet 295
> >	Date: 2013/05/22 23:18:56
> >	Author: obache
> >	Branch: HEAD
> >	Tag: pkgsrc-2013Q3-base
> >	Log:
> >	prevent to generate binary package in ${PACKAGES} from the side effect of
> >	`install' with USE_DESTDIR=yes.
> >	This changes prevent to unwanted overwite of existing binary packages with
> >	test installation (`stage-install', `replace' & `undo-replace', and so on).
> >
> >	To do both `install' and `package', you can still use `package-install' target,
> >	same as USE_DESTDIR=no.
> >
> >	Members:
> >		bsd.install.mk:1.13->1.14
> >		replace.mk:1.14->1.15
> >
> >A number of times since then, I've wanted to re-use a binary package,
> >but found it extremely difficult to do when it's not preserved any
> >more.  I've heard others express similar feelings, and finding out how
> >to change this is not easy -- you need to use the package-install
> >target -- and the docs continue to reflect the old behavior prior to
> >this change.
> 
> If you really want to re-use a binary package, you can use
> "make bin-install" instead of "make package-install".
> * always use binary packages for installation even on dependency if available.
> * binary packages will be created even on dependency if not available.

The problem here is that, using your suggestion, I would then need to
perform different actions - I would need to use a different target on
the command line.  For a long time, we've been using the same targets,
and have grown accustomed to their use.  That's why a definition is
needed, which controls the behaviou?r of the target.

Furthermore, I want to use packages I build, not ones which would
download from a different site, and over which I have no control.  But
that's secondary, the main reason I would like this is so that I can
type "make install" and have a binary package built for every pre-req
package and the package itself.
 
> >Unfortunately, my muscle memory does not remember this easily.  I've
> >become used, over the years to just typing "make install".  I'd really
> >prefer it if we could use a definition in mk.conf to drive the
> >decision to preserve binary packages or not.  Using a definition means
> >that I can set it once in mk.conf, and have it DTRT.  It would prevent
> >me trying desperately to stop "make install" after I've executed it,
> >only to delete it, and type "make package-install".  Similarily for
> >pre-requisite packages, which are built for me - I would not have to go
> >back and re-make them.
> >
> >So I've come up with the attached diff which does exactly this. I'm
> >not wedded to the names; however, I'm convinced that a definition would
> >benefit a number of us.
> >
> >Does anyone have any objections to this approach?
> 
> Your approach is not "keeping binary packages", but "always create binary packages".
> So you should use such naming, say "PKG_CREATE_BIN_PKGS=yes" instead of
> "PKGSRC_KEEP_BIN_PKGS=no".

I think this is a question of semantics - a binary package is always
created in the installation process, and it is then used to install
into the final ${PREFIX}.  So your suggestion might seem unusual to
some people.  As I said, I'm not convinced about the names, but one of
the bye-products of this proposal was that we discuss the preservation
of the binary packages that we build, because I'm not sure why your
change was made in the first place.

The original commit message mentioned replace and undo-replace, but
the results of the preservation are put into WRKDIR (this was done
specifically so that any binary packages were not overwritten). 
stage-install?  you mention "test installation", but most consumers of
pkgsrc are the ones who just want software installed; they are not
developers, and we should target them.  Ha ha.  I'm not a heavy
consumer of the "make stage-install" target, for example.  When would
a normal user use that?

Am I missing something in the bigger picture, though?  Why should we
not preserve/create binary packages?  The advent of binary package
managers require a package as a basic unit of transfer, and it makes
much sense to me to build binary packages all the time.

Disk space is rarely an issue these days, even on more expensive flash
devices, so I don't really understand why this change was made in the
first place, I guess.

Regards,
Alistair