[aur-requests] [PRQ#5845] Orphan Request for opensm

[james harvey]

AUR opensm-systemd-multiple-interfaces is now live, so that's another
choice too.  You should be able to install it without uninstalling
opensm, and pacman will ask you if you want to remove opensm and
install the new package all at once, so it won't force uninstalling
any opensm dependencies.  It just swapps them out.

On Thu, Jul 14, 2016 at 8:13 PM, John-Michael Mulesa
<jm.mulesa at gmail.com> wrote:
> Fair enough, I didn't realize that upstream had the functionality provided
> differently. I'll investigate making that work with my configuration.
>
> Thanks,
> JM
>
>
> On Jul 14, 2016 5:04 PM, "james harvey" <jamespharvey20 at gmail.com> wrote:
>
> 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 at 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 at 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/
>
>