Fwd: Time to mark portupgrade deprecated?

[Matthias Andree]

There's a discussion on freebsd-port@ about deprecating a port that
ruby@ is marked as maintainer for.

Thread start:
http://lists.freebsd.org/pipermail/freebsd-ports/2011-July/068887.html

It's unfortunate that Eitan didn't cross-post to the maintainer and I
didn't do it either, but anyways -- this is to make you aware.

-------- Original-Nachricht --------
Betreff: Re: Time to mark portupgrade deprecated?
Datum: Mon, 25 Jul 2011 11:36:47 +0200
Von: Matthias Andree <matthias.andree at gmx.de>
An: freebsd-ports at freebsd.org

Am 25.07.2011 10:50, schrieb Michal Varga:

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

You will do once it's the only tool.
OK, I wasn't being serious.  Seriously the point is that new users
should be kept away from a tool that is known to have lots of unfixed bugs.

> 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.
> 
> 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. Especially when portmaster
> is *NOT* a drop-in replacement.

Lack of port quality and maintenance are good reasons for removal.

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

Doug is aware of the problem, and it isn't a case against portmaster.
Frankly I haven't even tried if portupgrade would have been able to
handle it.

Anyways, there are various upgrades that *neither* of the two tools can
handle without manual help of the administrator.
   This frequently happens if a certain interdependent set of packages
(such as GNOME) moves functions between ports, or removes a port.

Basically I'd say let's mark portupgrade without EXPIRATION_DATE and
with DEPRECATED= and bump PORTREVISION, stating as reason that we need a
volunteer to maintain it and else people should use portmaster.  If
someone picks it up, problem solved.  If not, we at least scare new
users away and direct them to portmaster.

Marking the port DECPRECATED like that gives the maintenance problem a
much wider exposure than just repeated discussions on mailing lists that
no-one (in relation to the overall user count) reads.