Add CentOS packages and mark nss as patched

[dbn]

Summary

Commit message:

Add CentOS packages

 - add the following packages:
   - libicu
   - libunwind
   - lttng-ust
   - userspace-rcu (aka urcu)
 - fix pkg-plist for CentOS 7:
   - alsa-plugins-oss
   - alsa-plugins-pusleaudio
   - openssl

Test Plan

• exp-run: http://dbn.westeurope.cloudapp.azure.com/linux.html

[mmokhi]

Hmm, I don't know if my suggestion is wise and/or practical (so sorry in advance 😅 )
Because I saw linux-version of a port I maintain (lttng-ust), it just came to my mind that "can we have such ports via FLAVORs of the native port?"
How do you think about this?

[dbn]

In D13869#290962, @mmokhi wrote:

Hmm, I don't know if my suggestion is wise and/or practical (so sorry in advance 😅 )
Because I saw linux-version of a port I maintain (lttng-ust), it just came to my mind that "can we have such ports via FLAVORs of the native port?"
How do you think about this?

Although it is possible, I think it is cleaner to keep the ports separate due to the differences (and consistency with the existing linux ports). I think a better fit for FLAVORS would be CentOS 6 vs 7 ports, but even then there are many differents (such as version, distinfo) that make it less practical.

[mmokhi]

In D13869#291343, @dbn wrote:

In D13869#290962, @mmokhi wrote:

Hmm, I don't know if my suggestion is wise and/or practical (so sorry in advance 😅 )
Because I saw linux-version of a port I maintain (lttng-ust), it just came to my mind that "can we have such ports via FLAVORs of the native port?"
How do you think about this?

Although it is possible, I think it is cleaner to keep the ports separate due to the differences (and consistency with the existing linux ports). I think a better fit for FLAVORS would be CentOS 6 vs 7 ports, but even then there are many differents (such as version, distinfo) that make it less practical.

Thanks for the explanation.
Yeah it kinda makes sense now that I look at it from the point of view you are looking at.
Actually I think there are functionalities we can have as "Working properly" in a Linux port while it can be "Not working" in FreeBSD (or other way around 😅 ), So we can claim even the maintenance approach can be different. So yeah being separated makes more sense for these cases.

[dbn]

There are some failures in the exp-run. Alll relating to missing distinfo where the package is no longer hosted upstream. I'll submit an additional review to fix those issues.

Since thse errors above appears to me to be a preexisting error I don't think it is a blocker for this review.

[dbn]

bump rpm version for failing packages.

[dbn]

Fix missing pkg-plist. Exp-run now passes

[dbn]

I think this patch is ready to ship. Any comments or approvals?

[tijl]

Can you explain why you need the new libraries?

[dbn]

Update diff due to recent commits.

Pending work:

• Tidy up the patch for vuxml (i.e. revert from this patch).
• Check if the changes to EPEL break any of these new ports (they did not depend on setting SUBDIR).

[dbn]

In D13869#296333, @tijl wrote:

Can you explain why you need the new libraries?

We (mono@) need these libraries for our upcoming linux-dotnet ports (see https://reviews.freebsd.org/D13870).

[dbn]

Fix patch for:

• vuxml entry (ow committed)
• use SUBDIR for EPEL (per commit)

I believe this patch is ready for committing.

[tijl]

I think I committed everything.

[dbn]

All changes committed, thank you :-)

[russ.haley_gmail.com]

I'm cross posting an issue with the dotnet runtime, which was the reason this patch was created. Not sure where the source of the issue is yet.

https://reviews.freebsd.org/D13870

[dbn]

I've double checked and the issue does not appear to be with this revision. We'll work on the issue in https://reviews.freebsd.org/D13870 and if there is an issue relating to these Linux ports we'll report back.

[russ.haley_gmail.com]

In D13869#299136, @dbn wrote:

I've double checked and the issue does not appear to be with this revision. We'll work on the issue in https://reviews.freebsd.org/D13870 and if there is an issue relating to these Linux ports we'll report back.

+1