Re: pkgsrc-2013Q2 randomly not creating packages for me. What can be wrong?

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

On Tue, Jul 30, 2013 at 01:30:34PM +0200, Joerg Sonnenberger wrote:
> On Tue, Jul 30, 2013 at 08:13:11PM +0900, OBATA Akio wrote:
> > On Tue, 30 Jul 2013 19:42:29 +0900, Joerg Sonnenberger 
> > <joerg%britannica.bec.de@localhost> wrote:
> > 
> > >On Tue, Jul 30, 2013 at 09:26:42AM +0900, OBATA Akio wrote:
> > 
> > >>binary packages is useful to replace installed package,
> > >>but not required anymore after the replace.#
> > >
> > >I disagree, but I find keeping packages around instead of pkg_tarup a
> > >lot more useful and people insisted on keeping the latter.
> > 
> > Please describe use cases of binary packages in ${PACKAGES} after 
> > installation,
> > for over 50% users and not rare case.
> 
> It's the same reason why people wanted pkg_tarup. My point is just that
> it doesn't make sense to force people to install pkg_tarup for replace
> when preserving the binary packages would serve the same purpose better.

Some perspective on this:

I used pkg_tarup when I introduced the "replace" functionality so that
undo-replace would work just fine.  That's why the binary package is
created in ${WRKDIR}, since there's no need of it once the new package
has been found to be working well -- the binary package in WRKDIR was
not intended to be long-lasting.  In retrospect, I should have just
used a pkg_create invocation, the fluff that pkg_tarup brings is fine,
but not worth it.  Whatever.

Scroll forward 10ish years, and we now have binary packages produced
and managed by default.  The need for pkg_tarup in "make replace" is
no longer there, since binary packages are preserved by default at
build time.

The corner case is the one where an old package is installed, and
where there is no binary package for it.  I'd say that there weren't
many of those, if any, and we should be optimising for the most common
case at all times.
 
Which leads me to my conclusion - rather than discuss the symptoms,
let's fix the root cause - check whether a binary package exists when
doing "make replace", and, if there isn't one, make one (by whatever
means, I'm fairly sure a pkg_create invocation would do the job).

Regards,
Alistair