Updating ports

[Peter Schuller]

> I don't understand this statement.  I have killed portupgrade on numerous
> occasions, both locally and remotely, and have never had a problem
> restarting later.  If you mean portupgrade doesn't restart where it left
> off, then yes, that's true, but only in the sense that it goes through all
> the ports checking for upgrades before returning to the build you left off
> at.

Actually I was wrong because portupgrade doesn't do what I want  at all to 
begin with, so because nothing was ever started "correctly", there is nothing 
to resume "correctly".

The intended situation was:

Mini-port tree contains:

A
B
C
D depends on C

Now, C is updated in the tree.

You issue: portupgrade -r C

If all goes well, C is rebuilt followed by D. But if interrupted after C, D 
won't get upgraded on a subsequent run because portupgrade does not know C 
was upgraded.

Of course, this is based on portupgrading doing that to begin with and AFAIK 
this is not the case. I am not sure if any such logic is possible at all in 
fact.

portupgrade -rf C works of course, ***IF*** you know that C was upgraded. What 
I lack is a "portupgrade -a --force-if-dep-was-upgraded", and even if that 
existed, the re-start problem would remain unless the fundamental approach 
was changed.

(I have been meaning to fix this with my own package manager, but the project 
has been stalled for a while.)

> I *really* don't understand this.  I can count on one hand the number of
> times that I've run into dependency problems with portupgrade, and all of
> those were addressed in /usr/port/UPDATING or by simply deinstalling and
> reinstalling the port in question.

I would love to hear what I am doing wrong. I have just never ever had good 
experience with it.

Everywhere you read on mailinglists or wherever, you have people recommending 
various versions (portupgrade -a, portupgrade -arR, etc) but none of it ever 
works over time for me.

Firstly,there are these stale dependencies that are never explained anywhere 
as far as I can tell. I am also suspicious of the methology used that causes 
any kind of database / dependency inconsistencies as a matter of expected 
procedure. The job of the tool is to get my installed packages in synch with 
the ports tree; there is no possibilities for "stale dependencies" here as 
far as I can tell, except in some very specific cases. But everywhere I look 
in online resources these stale dependencies seem to be treated like some 
kind of unexplained-yet-necessary fact of life that nobody understands but 
that everyone seem to have a vague sense about.

(I do realize upgrading is difficult in several fundamental ways; I wrote 
pkgmanager to do in-place upgrading for pkgsrc in a manner similar to 
portmanager - so I do have some experience with this. The re-write of 
pkgmanager to also support ports is what I refer to above. But with all the 
kinks of pkgmanager, the fundamental approach worked very well in practice, 
modulo some issues that have to do with lack of implementing particular 
cases, or fundamental problems in the underlying package management system.)

Secondly there are various magic failures that start happening as a result of 
some dependency X being upgraded (or NOT upgraded) such that the other 
package Y depending on X breaks. This typically gets resolved by concluding 
that "ok, it's all borked, I'll portupgrade -rf Y" (or portupgrade -Rf X, 
depending)). Generally, these failures can be characterized as being such 
that they do not occurr if you 'make install' on a clean system with a 
consistent ports tree, but only occurr as a side-effect of problems with the 
upgrading procedure directly, or indirectly because packages are tested on 
fresh trees and do not stress dependency edge cases.

Note that all this is specific to wanting to synch ALL packages. I never go 
around "sniping" at particular packages since i consider that to be a 
fundamentally broken approach in most situations. I just want to have 
everything upgraded to their latest versions (with security fixes), not have 
to micro-manage individual packages.

Also, I do pay attention to /usr/ports/UPGRADING, but issues accounted for 
there definitely to not cover all the problems.

Actually. Is there anyone heavly involved with ports that might be interested 
in discussing some of the issues having to do with upgrading? I have my own 
private little vision of what I want to see from ports/pkgsrc itself to 
enable package managers to support seamless upgrading. If there could be some 
cooperation going in terms fo enabling upgrading tools to work better, I 
might be more motivated to finally resume work on that pkgmanager rewrite.

-- 
/ Peter Schuller

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20071224/089a7185/attachment.pgp