Hi Nilesh,
On 2024-04-16 17:03, Nilesh Patra wrote:
On Tue, Apr 16, 2024 at 04:52:01PM +0300, Andrius Merkys wrote:
On 2024-04-16 15:04, Nilesh Patra wrote:
OTOH, does anyone actually use s390x for any med team package? If not, can we
consider to add this too along with other 32-bit archs to our policy?
Personally, I do not like the idea of deny-listing architectures in team
policy. But I am not an uploader of emboss, I merely care for it as a
dependency for oscar4.
Sure, but if there is no user for those packages at all on s390x, would that not
translate to:
a) extra maintenance
True.
b) more build cycles / load on porter machines / more cost so on?
I think this is a reasonable price to keep an architecture among release
architectures.
I would suggest the following course of action for emboss:
1. Add a build-time test calling emboss executable(s). This way builds will
fail on s390x (and possibly other architectures) until #1069098 is fixed.
2. RM emboss for s390x without excluding s390x from build architectures.
This way emboss will be able to migrate and there will be no action needed
if/when #1069098 is fixed.
Makes sense to me.
I have added the build-time test and filed the needed RM bugs + removed
python-biopython test-dependency on emboss on s390x.
Best,
Andrius
