[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: MuseScore vs. the buster release



Hi Thorsten,

I've been a bit off from Musescore development, and I even didn't know
they had released a 3.0 (yay!). I have nothing against your plan, and
I'm happy that you have one :)

I'm playing with some Musescore bugs during our BSP in Montreal but
won't touch the package without coordinating with you first.

Thanks for taking care of this package.

Bests,

On Fri, Nov 30, 2018 at 07:29:27PM +0100, Thorsten Glaser wrote:
> 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) ;-)

-- 
tiago


Reply to: