pkg_chk replacement?

[Peter Schuller]

> >   pkgmanager attempts to alleviate these problems by upgrading all
> >   packages "in place" without needing to remove all packages that require
> >   the package being upgraded.
>
> And this behaviour is exactly what I wouldn't want to use on a server,
> since it means a lot more russian roulete (e.g. are minimum requirements
> correctly specified? did the ABI of a package really stay consistent
> etc.). Enough developers don't fully understand ABI issues, that's why
> "(b)make replace" is and always will be marked as dangerous.

I gotta chime in here, even if late, and even if I am biased.

First off, please note that pkgmanager does not care about minimum version 
requirements of similar. It upgrades *all* packages to their *latest* version 
in the order demanded by the dependency graph. Any packages depending on 
packages that have been upgraded or otherwise rebuilt, are also rebuilt. In 
this fashion it is more comparable to 'portmanager' than 'portupgrade'.

In fact, part of the reason I wanted and wrote pkgmanager was exactly 
*because* I got tired of dependency issues caused by incorrectly specified 
version requirements (aside from the general upgrading issue). The whole idea 
is to produce a system which is equivalent to what you would have gotten had 
you de-installed all out-of-date packages and then re-installed them - but 
hopefully (but not always) not have your workstation crippled for a couple of 
days while doing it.

In addition, if you are comparing the use of pkgmanager to seriously maintaing 
a separate jail, upgrading everything there and producting binary packages, 
and then do a binary upgrade of the host system, then sure, I fully agree 
that pkgmanager is obviously less safe. But noone has claimed otherwise. 
(Though I hope to have pkgmanager do exactly that in the future, 
automatically.)

But let me ask: How many people actually *DO* this? There is no simple 
out-of-the-box and supported way to do it (even using pkg_chomp it get's more 
compilcated than 5 minutes of manpage reading).

How many people even *WANT* to do this for their non-super-important servers 
or their desktop system?

With FreeBSD ports (mentioning it since it was brought up in the comparison) 
you at least have an out-of-the-box half-decent and supported method of 
ugprading. Sure it breaks, and sure I have done my fair share of cussing at 
broken dependency handling in ports etc... but at least it *works*, for some 
definition of it.

With pkgsrc, you basically have no out-of-the-box option for easy upgrading. I 
stopped using NetBSD alltogether for a period just because I got fed up with 
the pkgsrc upgrading issue.

Hence, pkgmanager. And hence, the non-focus on being 100% correct in the 
beginning - since that is already possible if you take the time to do it 
right manually. The aim is to have a tool which *easily* allows you to 
perform a global upgrade without a lot of hard work.

If you are a pkgsrc newbie wanting to "just upgrade", you are not appreciated 
being told "well, set up your own jail, do a builk build of all packages and 
then perform a binary upgrade". If you come from any Linux dist or from 
FreeBSD, you expect *some* usable upgrade mechanism to exist out-of-the-box 
(breaking your entire desktop for 48 hours after 'make update' removed 
everything right of the back does not count as "usable").

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller at xxxxxxxxxxxx>'
Key retrieval: Send an E-Mail to getpgpkey at xxxxxxxxx
E-Mail: peter.schuller at xxxxxxxxxxxx Web: http://www.scode.org