In interactive mode (-i), portupgrade asks for each package whether to upgrade it. If some upgrade is rejected by operator, it excludes packages which are depended on it from following consideration. Adding -k to command line doesn't fix it for all packages except topmost one (specified in command line). This is conceptually incorrect. Package relations are protected by requirements in port Makefiles (*_DEPENDS) including package presence and version. Portupgrade should not add additional restrictions to its, and if some package is present and have enough version, portupgrade should not add unnatural intelligence rejecting to build another package depended on first one. This portupgrade feature isn't original; it has appeared approx. in 2008. Before this, portupgrade behavior was correct - it differed installation problem and explicit reject. How-To-Repeat: Get an old system (e.g. with Xorg 7.3) and try to upgrade top-level packages (as Firefox) without upgrading low-level ones.
Responsible Changed From-To: freebsd-ports-bugs->sem Fix synopsis and assign.
Responsible Changed From-To: sem->ruby sem@ has turned over maintainership of portupgrade to the ruby mailing list.
Responsible Changed From-To: ruby->pgollucci I will take it
Responsible Changed From-To: pgollucci->freebsd-ports-bugs going to have enotime for the next 2 weeks, sorry
Responsible Changed From-To: freebsd-ports-bugs->ruby Over to maintainer(s).
State Changed From-To: open->closed Your proposal contains a lot of footshooting potential for the unaware user. I think the current behaviour is the right one. If you want to update a port without updating its dependencies first, you are running an unsupported setting and a lot of problems can occur.