port upgrade outdated order

[Mihai Moldovan]

On 04.03.2015 03:26 PM, Brandon Allbery wrote:
> On Wed, Mar 4, 2015 at 6:29 AM, René J.V. <rjvbertin at gmail.com
> <mailto:rjvbertin at gmail.com>> wrote:
>
>     So to you it's OK if a port fails to build because it pulls in
>     things from an earlier, installed version of itself that were not
>     blocked because the feature was not enabled, and do so without as
>     much as an explanation?
>
>
> Port bugs are never OK. A diagnostic/debugging mode that is forced on
> in some port as a hackaround for port bugs instead of fixing the port
> is *also* never OK.

That's generally true. I do however think that port maintainers can not
be asked to willy-nilly fix *complex* broken build systems.

Our current workaround for this is the conflicts_build PortGroup, which
bails out and asks the user to deactivate the port in question. This is
ugly for several reasons:
  - it requires interactivity
  - a deactivated port is not listed in ``port outdated'' and can NOT be
used with ``port upgrade'', but must be re-installed with ``port
installed''. This is totally counter-intuitive. (And yes, I know, not
mentioned anywhere...)

Forcing trace mode for those specific ports would at least, though not
fixing the underline cause, fix the problems listed above.

Maybe I'm biased, because I'm directly affected by this. I've had users
complain explicitly about this, though.



Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150304/e7752262/attachment.sig>