MuseScore vs. the buster release
Hi everyone,
I’ve looked at the development of MuseScore 3 and have made some sort
of plans for it and buster:
I’ll keep MuseScore 2 in unstable/testing in order to have it
available and in good shape in buster and stretch-backports,
and, for *buntu 12.04, 14.04, 16.04, 18.04 and 18.10, the PPA.
MuseScore 3 will break many things, so users will want to have
both available. Furthermore, we will *not* be able to backport
it to Debian stretch, as it won’t work with Qt5 from stretch,
and (in contrast to 2.3.2 and jessie) it’s not feasible to patch
it to make it so. (I’m working together with upstream on the
new release, and we analysed this today.)
I’m currently making git master (what will eventually become the
3.0 release) available as “musescore-snapshot” package in Debian
experimental (and the PPA for 18.04, can do later releases on
request). This is coïnstallable with “musescore” and will be
available on all Debian architectures that can run Qt5 (some of
the ports architectures that lack LLVM have issues with 5.11;
5.10 would be enough, but we’re not having it), avoiding the
new but optional QtWebEngine dependency.
My current plan is that, if MuseScore 3.0 is released before
buster (which is likely), that the “musescore-snapshot” package
will switch to tracking 3.x releases (a 3.0.1 bugfix followup
is pretty likely, perhaps multiple of those). The idea here is
to exercise the coïnstallability.
In the longer term, I’ll wish to have the “musescore” package,
first in experimental perhaps, then in testing/sid *after* the
post-buster-release unfreeze, switch to 3.x (which then will
replace 2.x on users’ systems), available via backports.
I don’t think musescore-snapshot should ever leave experimental
(it’s currently sitting in NEW but let’s give ftpmasters some
time to process it; the PPA already has it), and I also don’t
think we should introduce a new musescore3 package, mostly
because upstream won’t care about musescore2 bugs, so bullseye
won’t carry it (I’m still targetting src:musescore for 2.x for
buster, as I intend to maintain it and for stretch-backports).
So, please, even if you see newer versions popping up upstream
and/or in the packaging repository, don’t upload them, I have
a plan. Which is unlikely to survive first contact with the
enemy, of course, but nevertheless.
I hope the plan is agreeable to you.
Now, downstreams, such as *buntu studio, KXStudio, etc. (feel
free to disperse this eMail to those). Those *might* want to
have coïnstallable MuseScore 2.x and 3.x packages, and perhaps
for a much longer time.
Please do contact me, if you do, and we might be able to
arrange something, considering package names, executable names,
Provides/Replaces/Conflicts, etc. — I’ve got ideas how to handle
these, but (as outlined above) we’re probably not going to have
both in any given Debian version at the same time, so I’m not
going to implement those plans in Debian itself.
The absolute lowest for MuseScore 3.x is Debian buster (10, not
yet released) and *buntu bionic (18.04). If a downstream based
on an older release wishes to ship MuseScore 3.x we’ll have to
backport the buster/bionic Qt5 versions to them. They will then
have to check on their own whether this breaks any of the other
applications — I’d suggest a chroot instead; I’m reasonably sure
that the stretch kernel can run a buster chroot and the xenial
kernel probably can handle a bionic chroot. Do not toy around
with LD_LIBRARY_PATH or contaners, please; it’s much more main‐
tainable without.
But, whatever you do, talk to me and we might find something,
if you’re a Debian-based distro.
Thanks for listening and possible feedback,
//mirabilos
--
[17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker:
veni, vidi, fixi(t) ;-)
Reply to: