Fedora Account System
Red Hat Associate
Red Hat Customer
It has been pointed out[1] that the MuseScore package name (mscore) is rather unusual and confusing. Is there anything preventing it from being named 'musescore'? If not, for the sake of simple clarity (and also to better follow the packaging guidelines), please consider this a request to rename the package. [1]: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5290#c1
I just took over maintainership of the package last summer, and I have to admit that I wondered about the "mscore" name myself. This request is reasonable. I will work on the rename.
Back then when we first packaged musescore, "mscore" was the name of the tarball as well as the sourceforge project name https://ftp.osuosl.org/pub/musescore/releases/ https://sourceforge.net/projects/mscore/ While I don't have any attachment to the "mscore" name, I want to emphasize that it was compliant with the package naming guidelines when it was originally packaged. The package already has the Provides musescore. The effort to get it repackaged with a new name could be spent on other things, e.g. packaging fluidsynth2; but that's not my call.
(In reply to Orcan Ogetbil from comment #2) > I want to emphasize > that it was compliant with the package naming guidelines when it was > originally packaged. Agreed, and I apologize for implying otherwise in the initial request. There are no guidelines compliance issues that I'm aware of with the current mscore package name, and this request is not in any way about compliance to the guidelines. That being said, I still feel the rename is worth doing for reasons OTHER than compliance, and even absent any guidelines issues I'd still make the same request. Strike the "(and also to better follow the packaging guidelines)" part of my original request, and replace it with something like, "(and also to align it more closely with current packaging best practices, for the benefit of the user community)", as that's closer to the argument I really wanted to make. > The package already has the Provides musescore. Which is fine for the packaging _system_, it makes DNF work like it should... and it's probably good enough for other _packagers_, even... but it doesn't really help the users much, does it? I mean, this is not an ideal situation: $ sudo dnf search musescore ========================== Summary Matched: musescore ========================== mscore-fonts.noarch : MuseScore fonts mscore-doc.noarch : MuseScore documentation $ sudo dnf search mscore ========================= Name Exactly Matched: mscore ========================= mscore.x86_64 : Music Composition & Notation Software ============================= Name Matched: mscore ============================= mscore-doc.noarch : MuseScore documentation mscore-fonts.noarch : MuseScore fonts $ sudo dnf list \*musescore\* Error: No matching Packages to list The main package doesn't even _come up_ on a search for "musescore", because that name is NOWHERE in its basic metadata. If it wasn't for the subpackages, it'd be impossible to find. Midnight Commander is in much the same situation, just to pick another example I'm aware of. It's packaged as "mc", its Summary line is "User-friendly text console file manager and visual shell", and basically unless you already KNOW it's there, it's practically impossible to find. `dnf search` queries for "midnight" "commander", "command"... all of them will fail to find the "mc" package, just a ton of false positives. > The effort to get it > repackaged with a new name could be spent on other things It COULD be, absolutely. And /maybe/ it would even be better spent on that... but maybe not. Everyone has to make that determination for themselves. But, I don't really think it'd be all THAT much effort. (The required re-review will be the lion's share of it. And that part is a chore, granted. But it's also a good opportunity to freshen up our packaging, especially in older packages that may be grandfathered in to a lot of outdated practices and tooling.) And if the whole thing should prove to be more trouble than it's worth, I would fully support a decision to abandon the attempt. The point I'm trying to make, though, is that — while, yes, there are always other things that also need to get done, renaming a package from a borderline-nonsense name, to its ACTUAL name (so that users and potential users can actually find it and install it easily...) IMHO, that's not *wasted* effort. There's value in doing that kind of stuff, too. How much value, like I said everyone's gotta make their own call no that. So, if Jerry is willing, then the time and effort will be much appreciated. And I'll be happy to pitch in, if I can be of any help.
Sorry, I had other more urgent matters to attend to first. I've finally done the rename. See bug 1794971. A review would help speed things along. :-)
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.