peter.schuller at infidyne.com
Mon Dec 24 15:58:37 PST 2007
> 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
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:
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
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
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
(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
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20071224/089a7185/attachment.pgp
More information about the freebsd-questions