script name conflict: imtest

[sanjayankur31]

Looks like imtest is a command already provided by another software: cyrus-imapd

  - file /usr/bin/imtest from install of python3-fslpy-3.13.3-1.fc39.noarch conflicts with file from package cyrus-imapd-utils-3.6.0-9.fc39.x86_64
  - file /usr/share/man/man1/imtest.1.gz from install of python3-fslpy-3.13.3-1.fc39.noarch conflicts with file from package cyrus-imapd-utils-3.6.0-9.fc39.x86_64

In such cases, it's usually the software that used the name first that keeps it. I think cyrus-imapd's usage of imtest predates fslpy's here. Would you please consider using a different script name?

Downstream bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=2227990

[pauldmccarthy]

Hi @sanjayankur31, this is unfortunately not a trivial change for us, as there are several hundred calls to $FSLDIR/bin/imtest in other FSL scripts/applications.

However, if I understand correctly, you're only packaging fslpy so that you can package FSLeyes, right? FSLeyes doesn't use the imtest command, so you could safely re-name it in your fslpy package without affecting FSLeyes at all...

P.S. You're correct in that cyrus-imapd claimed the imtest name first, although it was only by a few years! The imtest script has existed in FSL in one form or another since 2004 :)

[sanjayankur31]

Hello,

Thanks for that. No worries. I'll first speak to the cyrus-imapd maintainer to see if they'll rename their imtest if it isn't used as widely as fslpy's imtest. If that fails, I can rename it to fsl-imtest i guess and document it in our package? (I wish there was a way to do it conditionally---if cyrus-imapd is installed, rename, otherwise don't, but I don't think rpm supports that. I'll ask on our developers list to check).

[sanjayankur31]

PS: packaging fsl etc. is on our very long list of todos, we just haven't gotten down to it yet:

https://pagure.io/neuro-sig/NeuroFedora/issue/57

https://pagure.io/neuro-sig/NeuroFedora/issues?tags=T%3A+Software&status=Open

fsl's license includes a "non commercial use" clause IIRC, which means it's not really FOSS and cannot be included in Fedora proper---but perhaps in RPM Fusion.

It's also on my list to speak to the maintainers to see if they'd remove that clause from their license, but I'm not hopeful.

[pauldmccarthy]

It's also on my list to speak to the maintainers to see if they'd remove that clause from their license, but I'm not hopeful.

This is unlikely I'm afraid - the FSL team (of which I am a part) are somewhat "locked in" to the terms of the commercial license, so it is unlikely to change any time soon.

We have recently made some packaging changes to FSL though, and have made all of the source repositories publicly visible, which make your life easier. We are now distributing FSL as a set of modular conda packages (conda, being platform-agnostic, is the best distribution option from our point-of-view). You can find more information about this at https://git.fmrib.ox.ac.uk/fsl/conda/docs

[sanjayankur31]

Thanks, sounds good. Yeh, I guess if you have a conda based system going, that's probably best for users. Our "dream" would be to have a custom Fedora based OS with all FSL bits set up on it so that people can use it "live" or just download and install---it'll have FSL plus lots of other useful utils (like the comp-neuro image we have at the moment) . The non-commercial clause makes that harder, though, since FSL can't be packaged for Fedora, which means it can't be part of a live image generated officially by the Fedora communty.