Time to mark portupgrade deprecated?

Matthias Andree matthias.andree at gmx.de
Mon Jul 25 09:36:56 UTC 2011

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.

More information about the freebsd-ports mailing list