Time to mark portupgrade deprecated?

[Michel Talon]

Jerry wrote:

> While we are on the subject of port management tools, I still use
> "portmanager" when a version bump on a port requires that a massive
> number of dependencies be rebuild. I have had all too many instances
> when both "portupgrade" and "portmaster" simply bombed out and left me
> with only a partially updated system, and in many cases, a virtually
> useless one. Portmanager would simple get the job done right the first
> time. It might be overkill for one or two port upgrades; however, it
> works fine on massive projects that seem to bewilder the other two
> competing contenders. The "p5-libwww-5*" example in the case of
> "portmaster" being a perfect example.

This subject of port management tools is a subject i have been much
interested in some years ago, and i must say that the problems which
seem to surface now in the general consensus, i had discussed them 
without any echo at the time. Having a system partially updated hence 
requiring a lot of work to fix with portupgrade happened to me several
times. Horrific slowness of portupgrade was perfectly obvious years ago.
I think most of the problems come from errors in the ports themselves
so are unfixable through ameliorations in the upgrade tools. I think
only a more rigorous management of the ports, i mean something like the 
separation between unstable, testing, stable in Debian, with rigorous
procedures for going from one state to the better one could cure this
problem, but at the expense of slowing the development. More
importantly, only a procedure centered around *binary* packages could
possibly lead to a guaranteed decent state of the ports. Centering
things around source code can only lead to confusion, incessant messing
by both developers and users with various options etc. which can only
destabilize the system. Anyways, to come back to port management tools 
i don't know how portmanager works, but i think that both portupgrade
and portmaster have a fundamental flaw in that they both work locally,
upgrading one port after another until the job is finished, which means
that the state of the machine is constantly modified, possibly into
a broken state, without any possibility for the user to know beforehand
that he is headed to failure. A proper tool should do a first pass
describing exactly the initial state and the final state so that the end
user can choose to upgrade or not. This is what Debian apt-get (or
aptitude) does, it describes before any destructive action begins what
will be removed, what will be installed. This can only work reliably if
you have binary packages, otherwise you can never be sure that a source
port will compile. The only *BSD i am aware of that has moved in that
direction is OpenBSD. From what i hear, people are happy with the
management of ports in OpenBSD, while most of people i hear are very
unhappy with FreeBSD ports.




-- 

Michel TALON