Re: pkg_tarup inclusion in pkg_create

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Tue, Jan 03, 2012 at 01:15:38PM +0100, Aleksey Cheusov wrote:
 > >  > The DESTDIR support removed most reasons for doing modifications to
 > >  > the file system without safety belts and can also make sure that
 > >  > such a binary package is always around.
 > > 
 > > As has been noted before, no it can't.
 > > 
 > > Not necessarily disagreeing with the conclusion though.
 > 
 > Where can I see previous rounds of this discussion?

Here, AFAICR. Try seaching the archives for "undo-replace".

Basically, what happened was that destdir mode broke undo-replace, and
the argument was over whether that mattered.

On the one side, the claim was that with destdirs enabled the previous
package you had will already be in your packages/ dir, so undo-replace
is pointless and you should just go install that package explicitly
when needed.

On the other side, the claim was that blindly accumulating package
tarballs for everything you build (until manually pruned) is a bug,
not a feature. Meanwhile, all it does is accumulate each distinctly
numbered version of the package, not each copy you compile. This means
if you recompile the same version, but the results aren't the same
(and e.g. it doesn't work) it overwrote your previous package and you
can't back out. Theoretically this isn't supposed to happen; but when
it does is exactly when being able to back out is important. It's
similar to the enormous argument threads about module paths and kernel
versions in tech-kern.

Eventually the latter reasoning prevailed (although I think Joerg
still isn't convinced) and obache fixed undo-replace. However, we're
still blindly accumulating package tarballs that still require manual
pruning.

A better scheme would be to explicitly retain the last N compiled
versions of each package (where N is configurable) regardless of their
version numbers; that would fix all these problems, probably allow
nuking pkg_tarup, and make undo-replace much more robust. However, it
would require rearranging a lot of things (including e.g. the layout
of the binary package tree) and is therefore not trivial.

-- 
David A. Holland
dholland%netbsd.org@localhost