That being said, I do like the idea of (and have released) extra AUR packages that have features added. Momentarily there will be a new AUR package opensm-systemd-multiple-interfaces which will have Fedora's extra configuration file functionality. It will be dependency-compatible with opensm, so you can uninstall opensm and install opensm-systemd-multiple-interfaces. On Thu, Jul 14, 2016 at 7:17 PM, james harvey <jamespharvey20@gmail.com> wrote:

opensm AUR package follows Arch's philosophy of vanilla upstream releases, when possible. The AUR package's only deviation from upstream is that it includes systemd support, which upstream does not.

Contrary to your statement, the opensm AUR package has functionality for multiple interfaces, because upstream (openfabrics.org) has it. Their functionality requires the sytem to have a opensm.conf file for each interface.

What I think your complaint refers to is that the opensm AUR package follows the developer's (openfabrics.org) way of providing the functionality, versus the way Fedora provides it. Fedora does it differently for two reasons.

First, Fedora looked at it and said for most users, each interface's opensm.conf file would be identical except for the GUIDs. So, they made an extra configuration file to a single opensm.conf could be shared between all interfaces, and the extra configuration file would only have the GUIDs.

It's not that I don't like that option. I just really like Arch's vanilla where possible philosophy. The main reason I switched to Arch is so when the developer changes something, you don't have to wait for the linux distribution to adapt their changes to the new releases. And, I don't think Fedora's "we don't like how they did it" philosophy justifies a deviation here, when the functionality is there and works, just in a way they wouldn't have made it.

Second, Fedora noted they didn't like when a user upgraded packages that the user's multiple interface configuration would be overwritten during the upgrade. I'm not sure how Fedora handles /etc files during upgrades, but we have pacman, so we don't have this problem. When pacman upgrades a package with a new config file, it writes to a .pacnew config file. The system maintainer is expected to handle the changes, if needed, and there are programs such as Dotpac which can help with that.

Please tell me where I'm wrong, I'm certainly open to re-evaluating my position. But, I think if you want a simpler way to run multiple interfaces than how upstream wants it to happen, that's a dicussion to have upstream, not in Arch's AUR. I'd probably even give a thumbs up to such a change, if it were made upstream. There's no reason why they couldn't have their /etc GUID parameter either be a single GUID, or a comma separated list.

On Sat, Jul 9, 2016 at 4:30 AM, <notify@aur.archlinux.org> wrote:

...

jmsq [1] filed a orphan request for opensm [2]:

Useful code for multiple interfaces gutted out of opensm.launch and never reintroduced.

[1] https://aur.archlinux.org/account/jmsq/ [2] https://aur.archlinux.org/pkgbase/opensm/