Time to mark portupgrade deprecated?

[Torfinn Ingolfsen]

Hi,

On Tue, Jul 26, 2011 at 11:27 AM, Michel Talon <talon at lpthe.jussieu.fr> wrote:
> 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

The subject we were discussing was portupgrade; if you want to discuss
something else, please start a new thread.
Thank you.

> 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.

I would say that "most people your hear" isn't a representative subset
of all the people who use ports.
In my experience anyway.
-- 
Regards,
Torfinn Ingolfsen