Call for help: maintenance of the musescore snap

Thanks for your reply!

Unfortunately I don’t understand the question because it seems the snap community uses the term “installed” as a kind of specialized internal lingo rather than the everyday meaning it has to most sysadmins.

So I’ll try to answer your question by describing what I really want. The list is bigger than just an answer to your question, but the list does contain my answer to your question, which is that when a binary that I’ve received via snap exists unpacked on my machine in executable form, I should be able to run it without reconfiguring my machine. So, for example, both versions 169 and 190 of the MuseScore snap are on my machine right now. Does this mean they are “installed?” I don’t know. But at least one of them is installed. Without changing what’s installed on my machine, I should be able to run both of those binaries (different versions of MuseScore) simultaneously, side by side on the machine. I think this is my answer to your question.

  1. Before changing any software on my machine, I want snap to present me with a list of proposed updates and let me decide whether to accept each one and choose when the updates are applied. In other words, I want it to act like apt can act when configured the way I prefer.

  2. I want to be confident that snap will not delete the version of MuseScore that I’m currently using because the new version seems to be broken.

  3. I want new versions of software installed with snap to inherit configuration / preferences / etc. from old versions that they are supposed to supplant or supersede.

  4. I want a snap containing a good (stable, non-developer, correctly configured build of) the latest version of MuseScore (3.6.1).

That’s several things, but I hope none of them are too crazy. It just seems like basic normal sysadmin stuff to me, but somehow (the current situation which includes) snap has taken all those basic things away, and when I google around for how to control snap I find only threads complaining about how it’s basically impossible to control properly because almost all its configuration is baked in, and what little configuration can be done at runtime is almost completely undocumented. :frowning:

Thanks again for helping!

just do a snap refresh musescore if you want to move forward again …

Thanks for that info!

How can I know when there’s a new version that I might want to move forward to?

well, you did call snap revert ... so you know you reverted from a newer installed version to the older installed one … refresh just rolls you forward to the lastest installed one again …

beyond this, it is all in the hands of the snap publisher, when she pushes out an update to a channel or track your are tracking and you are not currently rolled back, you will recieve it automatically.

to influence the automatic behaviour you have several options described on:

(there are special cases where snap publishers use the automatic self-test functionality of snaps where snaps roll back themselves automatically if the self test fails during upgrade, but thats (sadly) rarely used for desktop snaps and more typical for server snaps or apps on IoT devices)

Thanks for the pointer to that documentation. Unfortunately it confirms several perceptions that I had about snap that I feel are bugs.

To choose just one example, I can’t meaningfully query snap to see what the current setup is. If I do, I get empty information, like this:
$ sudo snap get system
Key Value
refresh {…}
seed {…}
$

And pretty much every item in that documentation explains some way in which snap will intentionally violate even the minimal configuration that I’m permitted to give it. Example: “After a refresh, the next refresh can be delayed by up to 60 days, after which a refresh will be performed regardless of the refresh.hold value.”

Additionally, the documentation itself has gaps that seem serious to me. One example is that, although that document explains that on my system the default behavior is to keep two versions of each snap, there is no information about what happens if I have reverted to the older version on my system and a new version becomes available. Am I forced off the old version which I had selected explicitly? If so, which of the newer versions becomes the “installed” one? Or does the newer version, the un-selected one in the case where I had reverted, get deleted in favor of adding the new one while retaining the one to which I had reverted explicitly? When such an update occurs, does my revert get undone so that I’m now using the new version, or does my revert still hold? Or if I revert, does it stop all automatic updates to that snap?

Those are important questions and I am disappointed that no answers seem available in the documentation, and that a system that seems somewhat immature (and also seems to be aimed against my goals as a sysadmin and user – so more maturity might make it worse, not better) has taken an uncomfortably large amount of control over the configuration of my machine without any good alternative.

Finally, there appears to be no way to get snap to do updates interactively, by which I mean that I would like a setup where it alerts me that updates are available and waits (an unlimited amount of time, possibly forever) until I say go ahead before installing them.

Aside from my concerns about snap UX in general, do you think anyone is likely to try to address the breakage of version 190 of the MuseScore snap?

Thanks again.

i personally report bugs usually via the contact link that is in the snap info output to get them fixed :wink:

Thanks, but I tried that. Their response was that they do not build snaps of MuseScore, that someone else does that and they are not responsible. They seem to share many of my concerns about snap and they seemed to hint that maybe I should try to avoid using it.

I don’t know why the “snap info” contact link is pointing to developers who do not support snap builds of their software.

well, looking at the snapcraft.yaml of this snap, the snap seems to just build the source from https://github.com/musescore/MuseScore from the latest stable tag and does not seem to patch it in any way and https://musescore.org/en/download says:

The latest stable version is 3.6.1

whatever makes it show “MuseScore3Developer” for you must have been added by the musescore developers …

What we would say about your machine is that you have multiple revisions of the MuseScore snap installed on your system, but only one of them is active right now. You can switch which revision is active amongst the revisions you have on your system using snap revert musescore --revision.

Parallel to all this, you can have multiple instances of a single snap, which are active and independent from each other. This means you would enable the parallel installs feature (which is still experimental actually), and then you could do this:

snap install musescore
snap install musescore_edge --edge

where edge there is the instance key, identifying a separate instance of the installation of musescore. Now you can run musescore or musescore_alt, and you can revert one of them to the older revision, etc. and keep one newer, etc. and they are independent instances of each other, with separate configuration, etc. This is the closest analog to what you expressed wanting with this quote:

That functionality is called parallel installs, and it only works when you have multiple parallel instances of a snap. Just having multiple revisions isn’t enough since you need to have multiple active revisions, and a single snap instance can have exactly one active revision.

Sorry that we don’t have this documented better, but I can explain to you the behavior:

  • If you have not used snap revert, then the older revisions go away as you upgrade
  • If you did use snap revert, the revision you reverted away from is marked as not usable and snapd will not refresh you to that revision, and that revision will be marked for garbage collection at some point. What happens then when a new refresh comes along, you will skip over the revision you reverted away from to the newest revision, and the revision you reverted away from should be garbage collected at this point if you are setup to only keep 2 revisions of each snap.

Snap data stored in certain directories such as $SNAP_DATA and $SNAP_USER_DATA is migrated forward to revisions, but not backwards to ensure that if the new version of the snap you upgraded to broke things in those directories, you can revert back and still have a working snap.

This will not happen as long as the revision you are using is active. After you refresh to another revision, it is marked inactive and will be garbage collected eventually when the number of revisions increases beyond the configured number of snaps that are retained (2 by default)

Thank you, that’s a lot of great information and indeed it seems to tell me how to do several things I was hoping would be possible.

One place where I’m confused is about the instance key. What is an instance key, and how do I find it? In the command “snap install musescore_edge --edge” you said “edge” is the instance key, so I presume I replace both occurrences of “edge” with the instance key in that command? I find that a little surprising but I guess it could work.

the “Instance Key” is simply the suffix to the name, you cant have an app called “musescore” twice on the system. the instance key is there to tell them apart, the --edge is only to show you can install the second one from a different channel:

snap install musescore_instancekey --edge

(you run the second installed version as “musescore_instancekey” instead of just “musescore” so the OS knows which one you want to start right now (they will happily run side by side))

Hi @RobertKennedy! And sorry for this late response. I will try to solve all the doubts I have answers for.

This is just some problem with the naming. If you take the git commit that it’s shown there, you will see that it’s the one for the stable release.

That, I don’t have an answer why. I’m sorry I can’t help more, but I don’t use MuseScore anymore, so my testing of new versions t it’s quite superficial.

Yep, that was me.
I did this in my free time and with good faith, but this is official in a way, or at least one member of musescore was aware at the time and gave me permissions to publish snaps.
That’s what I said that this should be moved to snapcrafters, that would make it clearer.

I can’t avoid problems from happening, but I’m sorry for your bad experience.

OK, folks, I really need help. The insanity has gotten out of control.

Unfortunately that turns out to be false. I left revision 169 active. And behind my back, with no action taken on my part, snap has deleted that revision from my machine, along with its successor (190) which had the problem, and has replaced those two revisions with two other revisions (194 and 199) which also both have the problem.

So, please, I am begging you. I need help because I cannot simply unplug my internet to keep this malware from continuing to infest my machine. And at this point snap is definitely acting like malware from my perspective as a reluctant sysadmin.

In earlier messages I asked for several things and they have not happened. I humbly request advice about what is the correct escalation path to get these issues addressed so that I can:

  1. control what software is running on my machine without disconnecting my machine from the net, and
  2. contact and hopefully get support from whomever is creating these broken builds of musescore that keep getting pushed to my machine against my will. I need to be in touch with someone who is willing to be responsible for fixing the problems with the stuff they are pushing. If they are not willing to work on the problems, and instead will insist on pointing a finger at someone else, I would humbly request that they stop building and pushing stuff they are not willing to take responsibility for.

Please, please, please, I need the madness to stop and I respectfully ask each of you what you would do in my position. I do not know how snap works, I trusted others here who claimed to know how it works, and who apparently happened to be mistaken, and I have no idea where to turn for help now.

Music typesetting is one of the main things I do with my linux machine, and now this malware has, to a significant degree, disabled or at least made much more painful that important function of my machine.

Please can someone point me to the correct process for obtaining help with this kind of problem? I don’t know why the entire snap-affected world is not crying out about this, or maybe they are and I’m looking in the wrong place, but I beg you, please help me. I’m grateful for the advice I’ve been given here but the most basic things in that advice unfortunately have not worked for me so I don’t have any idea how I can proceed to restore my machine to a stable, working state.

MuseScore is published to the Store by the upstream developers. They have listed https://musescore.org/en/support as the place to get support for the Snap package.

Thank you for trying to help, but please see earlier in the thread where I explained why your advice turns out to be fruitless: Call for help: maintenance of the musescore snap

Have you tried to see if you encounter similar problems with other builds of MuseScore, such as the flatpak version or the AppImage version?

Sorry if I wasn’t clear, but when I mentioned “after you refresh”, I meant both manually triggered refreshes as well as automatic refreshes that snapd does. In this case it seems that snapd performed an automatic update (2 of them in fact it seems). If you would like to control when refreshes happen on your machine, take a look at https://snapcraft.io/docs/keeping-snaps-up-to-date as @ogra mentioned above

The appimage version is built correctly. The problems with snap have forced me to abandon snap and move to the appimage, which is working OK, but it means musescore is now a one-off thing on my machine that I have to update via a manual process different from everything else, so it’s far from ideal.

The keeping-snaps-up-to-date page explains that automatic refreshes can’t be turned off and there is apparently no way to make snap obtain explicit approval from me each time it refreshes an app, and no way to make snap allow me to roll back to any prior revision and stay there.

Maybe I’m missing something (but people keep repeating the same stuff, so it seems like I’m not)… but this all seems like straight-up malware bot behavior on snap’s part and given my limited understanding at this time, I cannot for the life of me understand how anyone thought it could possibly be a good idea to design things this way. It’s truly disappointing and frustrating to have this thing on my system and to have some apps depend on it rather than use mechanisms that can be meaningfully administered.

I realize this thread was not supposed to be about the overall merits of snap per se, so I will try to contain any further rants. Hopefully someone is listening anyway.

Well, the situation is getting worse:

and if we don’t fix the building with cmake plugin, it will definitely block the snap from updating once version 4 is released.

I don’t have the time to work on this, but the snap is installed by almost 16k users and “featured” since July, so I really think it would be a pity to let it rot.

I think that the best would be for it to be taken over by @Snapcrafters as upstream is not really interested in having this.