Time to mark portupgrade deprecated?

[Doug Barton]

Change is hard. :)

I have no objections to someone (or some group) choosing to maintain
portupgrade. I've always said that I don't regard portmaster and
portupgrade to be in competition.

However if no one steps up to maintain it, portupgrade will eventually
bitrot and become unusable. So for all of you saying "save portupgrade!"
this is something you seriously need to consider.

That said, I was going to avoid responding to this thread altogether
however you said some things below that I felt compelled to respond to.


On 07/25/2011 01:50, Michal Varga wrote:

> 3. Switching to portmaster means retraining for a different *mission
> critical* software, that behaves differently, and that I currently have
> no need for, because the former one works fine. To point out a specific
> examply that I see frequently in UPDATING:
> 
>   If you use portmaster:
>   # portmaster -r icu
> 
>   If you use portupgrade:
>   # portupgrade -fr devel/icu
> 
> Ok, sure, easy task.. Hey..what? In portupgrade, -r builds all my ports
> recursively and updates those which are out of date, where -f forces it
> to rebuild every single one along the path. Clear, right? So why is this
> different for portmaster?

Because I never used portupgrade, and I never set out to create a
feature-by-feature replacement for it. More pointedly, there are certain
things about they way that portupgrade works that I don't like and/or
don't agree with; hence my desire to create a new tool.

> Where is my -f[orce] option? Will -r always
> rebuild everything? Or will it never, as it is with portupgrade without
> -f used? IF that's the case, how can my scripts recursively rebuild only
> needed stuff and...damn.

zomg, change is hard. :)

> Sure, by that time I spent on writing this email, I might have been
> halfway through portmaster documentation and have my questions answered,
> but that's obviously not the point - I just don't need, and don't want
> to.

zomg, change is hard. :)

> While portupgrade works (and it works), I don't want spending my time on
> cross-checking every single usecase between portmaster and portupgrade
> so that my upgrade scripts can safely play with the new popular kid on
> the block.

zomg, change is hard. :)

> Unless there is something fundamentally broken with portupgrade (other
> than a few open PRs) that prevents it from working on a modern FreeBSD
> system, I don't see a point in deprecation.

I tend to agree with you, actually, but ...

> Especially when portmaster is *NOT* a drop-in replacement.

This is a red herring, as portmaster is never going to be a drop-in
replacement for portupgrade.

> Again, from recent UPDATING:
> 
>   portmaster cannot process the upgrade of www/p5-libwww from version
>   5 to version 6. To upgrade p5-libwww, use portupgrade instead, or
>   deinstall p5-libwww before reinstalling:
> 
>   If you use portmaster:
>   # pkg_delete -f 'p5-libwww-5*' ; portmaster www/p5-libwww
> 
>   If you use portupgrade, no special treatment is necessary.

This issue arose because the maintainer of the port chose a non-standard
way of dealing with the issue of one package separating itself into 2
parts, and then chose not to apply the workaround that I suggested for
dealing with the problem; which turned out to be an example of an issue
that I brought up on the list a little while ago and was told that it
didn't need attention because if it happened it was always an error in
the port.

So just to be clear, if someone wants to maintain portupgrade and/or
people want to continue using it, no objection from me. :)

Meanwhile, the portmaster man page contains a very detailed treatment of
what portmaster does, and how and why it does it. Anyone considering
switching is encouraged to install it, and read the man page.


Doug (zomg, change is hard.)

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/