Re: how to upgrade a whole machine ...

[Aleksey Cheusov <cheusov%tut.by@localhost>]

> It actually *were* easy, IMHO, if only there weren't so many reasons
> for the end-user to build / update packages on his own, such as
> different pkg_options and obsolete / vulnerable packages in the
> binary repository. It seems to me that in order to be maximally
> ergonomical, there'd just have to be:

>  (i) up to date binary packages;
+1

>  (ii) binary packages for different option sets.
+1

> However, it has always been somewhat mysterious to me
> why bulk builds are done from scratch all the time instead of simply
> rebuilding updated packages.
Neither my distbb not pbulk rebuild already built and not updated packages.
distbb rebuilds only updated packages and packages that depend on
updated once.

See the logs 
  
http://www.mova.org/~cheusov/pub/pkgsrc-pbulk/Debian-etch/current/log/20080503.1258/META/report.html

distbb explicitly separates packages into four categories.

  ...
Packages built previously       4398
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ they all are NOT rebuilt

Packages built                  1227
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ actually rebuild
Packages failed                 959
Packages failed due to them     599
  ...

> How the packages are built, ultimately, should not
> be the end-user's concern
+1
The only missed thing in pkgsrc (useful for end-users)
is a tool for binary upgrades
that can work with MULTIPLE BINARY REPOSITORIES
just like Debian apt can do.
It is common situation when end users need to [re]build SOME/A_FEW packages
and is quite happy with binary packages in MOST cases.
Thus, we have two binary repositories: official ftp:/ftp.netbsd.org/...
and local binary repository.

Rebuilding packages is still needed for a number of reasons:
0) options (I'm personally quite happy with defaults)
1) wip contains lots of useful packages that are outside pkgsrc tree;
2) Many packages needs patches for plantforms other than NetBSD.

For single binary repository 'pkg_chk -b' is not so bad,
at least it supports pkg_summary(5) for ftp:// repository (in this case
it works rather fast). In case PKG_PATH=/local/path/to/rep
'pkg_chk -b' works horribly slow because it doesn't use pkg_summary(5)
in this case even it is available (it is always true in my case).

P.S.
One of the reason to create wip/pkg_summary-utils was easily
manipulating the binary repositories, that is summaries ;).

P.P.S
Feature request for pkg_chk:
file:// method for fetching package. This is in order to use pkg_summary(5)
if it is available - just like it is made with ftp://.

-- 
Best regards, Aleksey Cheusov.