Re: pkg_tarup inclusion in pkg_create

[Marc Espie <espie%nerim.net@localhost>]

On Tue, Jan 03, 2012 at 03:46:55AM +0100, Joerg Sonnenberger wrote:
> On Tue, Jan 03, 2012 at 03:30:54AM +0100, Julian Fagir wrote:
> > in the pkg_tarup comments you can read somebody proposing the integration of
> > pkg_tarup to pkg_admin. pkg_admin is not suited for that, but pkg_create is,
> > as it is the tool behind pkg_tarup.
> > I'm not much into the whole packaging thing, but I need this functionality, 
> > so
> > I numbly took over all the functionality of pkg_tarup to pkg_admin.
> 
> I am against this. pkg_tarup is essentially a hack for not keeping
> binary packages around. 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. More importantly,
> there are a number of cases where pkg_add $foo followed by pkg_tarup
> will not create the same state.

Let me chime in with my experience with the same issue over in OpenBSD...

pkg_tarup is your tool for rebuilding binary packages from installed packages,
I assume ?

Over in OpenBSD, we do support this for the most part, and it is indeed a
logical part of pkg_create (since most of the functionality is already there).
There are several good reasons for it.

- sometimes you're stranded without network, and you want to duplicate an
installation quickly, rebuilding the packages from an installation and
reinstalling them close by is good.

- pkg_create should know when it's going to be able to create identical
packages, which means requiring the systematic annotation of every file in
the package with crypto checksums, and of course, complaining if some are
wrong (and also annotating files with any crucial @mode/@owner annotations.

- this did require saving every script in the database, including install
scripts. That's very little overhead compared to the benefits (I don't know
if you're doing that already).

- as a result, one can also quickly check that the installation matches the
database (that you probably already do) or that the installation totally 
matches a given binary package (this requires comparing install script).

As another benefit, you can sometimes run more tests: grab an "orphaned"
installation, say where the binary packages have been lost/are no longer
available, duplicate it, and play with it. This has proven to be invaluable
for testing...


I agree that keeping binary packages around is a good idea. But you cannot
always do so, or sometimes the disk where you keep the binary packages will
get corrupted and then, what do you do ?

Keeping pkg_tarup as a "hack" is a solution, but it means you have yet
another set of non-integrated tools that work sometime, but need to be
maintained separately.

In my experience, the less codepaths that do the same thing, the better...

You have the OpenBSD point of view, I'll let you choose your own path.