Bug 243370 - TRYBROKEN equivalent for ONLY_FOR_ARCHS and NOT_FOR_ARCHS
Summary: TRYBROKEN equivalent for ONLY_FOR_ARCHS and NOT_FOR_ARCHS
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Port Management Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-15 09:57 UTC by Piotr Kubaj
Modified: 2020-01-16 11:41 UTC (History)
2 users (show)

See Also:


Attachments
patch to bsd.port.mk (601 bytes, patch)
2020-01-16 11:36 UTC, Mark Linimon
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Kubaj freebsd_committer 2020-01-15 09:57:36 UTC
I'd like to try building using poudriere bulk -a to see what ports marked as not for powerpc64 will build for this architecture.

TRYBROKEN is ok for this, but only when the ports in question are marked BROKEN_powerpc64. However, many ports have NOT_FOR_ARCHS=powerpc64 or ONLY_FOR_ARCHS=${SOME_OTHER_ARCHS}. Many of those ports build and work just fine on other architectures and have those entries because in the past, they didn't.

Would it be possible to extend the coverage of TRYBROKEN or add some other variable for ignoring NOT_FOR_ARCHS and ONLY_FOR_ARCHS?

This would help with ports testing on powerpc* architectures, but also on all ARM's and MIPS.
Comment 1 Mathieu Arnold freebsd_committer 2020-01-15 22:00:49 UTC
Well, TRYBROKEN is probably not a variable you want to change the semantics of.

For testing, on your side, the easiest would be to comment out lines 2749-2788 of Mk/bsd.ports.mk.

If you want something more maybe we could introduce a new variable, say, TRY_FOR_ARCH(S) that you set to an arch, and the lines I talked about earlier would be skipped if the current arch is that arch.
Comment 2 Piotr Kubaj freebsd_committer 2020-01-16 10:27:09 UTC
(In reply to Mathieu Arnold from comment #1)
AFAIK portmgr should sometimes do TRYBROKEN ports runs, so commenting out those lines would work for me, but I think the policy for ports builds is to build on vanilla ports tree.

The best approach would be a new variable. This can then be set up in Poudriere's make.conf.
Comment 3 Mathieu Arnold freebsd_committer 2020-01-16 10:43:37 UTC
portmgr's job is to maintain the framework and curate the ports tree.  We mark ports BROKEN when they have been failing to build for months.  And we usually deprecate them when they have been marked BROKEN for months afterwards.  So from the time a port stops building properly to the time it gets expires and gets garbage collected, more than a year elapses.

Ports have maintainers, they are the main people responsible for making the port work.  It is not the job of portmgr to maintain all the ports.
If a port expires because it is BROKEN, it means that is has been failing to build for so long nobody cares about it, and if nobody cares, there is no point in having it in the tree.
Comment 4 Piotr Kubaj freebsd_committer 2020-01-16 10:54:06 UTC
(In reply to Mathieu Arnold from comment #3)
I didn't mean setting BROKEN= (broken everywhere), but broken for specific architectures (BROKEN_armv7, BROKEN_powerpc64 etc.). Since many maintainers don't have access to all supported architectures, those entries usually stay even when the ports build on those architectures.
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2020-01-16 11:36:39 UTC
Created attachment 210791 [details]
patch to bsd.port.mk
Comment 6 Mark Linimon freebsd_committer freebsd_triage 2020-01-16 11:41:39 UTC
(In reply to Mathieu Arnold from comment #3)

> portmgr's job is to maintain the framework and curate the ports tree.  We mark ports BROKEN when they have been failing to build for months.

As pkubaj says, unless maintainers have a easy way to test on BROKEN_ARCH #n, they most likely won't.  And, we have never made it a requirement for them to do so.

IMHO portmgr running (quarterly?) TRYBROKEN runs on various architectures is something we should do.  OTOH that discussion is probably not within the scope of a PR.  If desired, I can start a thread on ports-developers@ or suchlike.