[CMake and run time dependencies] Re: Do not split QML packages

[Albert Astals Cid]

El dimarts, 15 d’agost de 2023, a les 8:42:09 (CEST), Sune Vuorela va 
escriure:
> On 2023-08-15, Nate Graham <nate at kde.org> wrote:
> > It's fairly common for runtime QML modules to get missed by packagers
> > and result in runtime breakage for users. The more QML libraries get
> > sliced-and-diced into tiny parts, the more opportunities there are for
> > this to happen.
> 
> I'm quite sure that we as packagers will stop having bugs in their
> packages the same time we as upstream stop having bugs in the software
> we produce.

This thread is not about "packaging bugs" in abstract, obviously mistakes 
happen and they can be fixed.

This thread about a policy that has been proven to be wrong (splitting one of 
our packages in multiple little packages) for a long time[*] and packagers 
seem to refuse to fix it. 

The policy may have seemed a good idea back then when it was introduced, but 
in my opinion the right thing to do [after it has been the cause of so many 
issues that could have been avoided] would be to reconsider it and ideally 
reach the conclusion of not splitting up QML packages into a multitude of 
small-QML packages.


> 
> What we as upstream can do to make our lives as packagers easier is to
> have a few sane[1] and trustable autotests that ensures at least basic
> functionality.

Why should upstream do anything to make the live easier for downstreams that 
decided to complicate their live by themselves?

As you pointed out, we have lots of actual bugs to fix, so helping with self 
inflicted bugs seems a bit of a waste of our time.

Cheers,
  Albert

[*] I was already suffering from this "split a single QML package into 
multiple sub-packages" issue back when i worked on the Ubuntu Phone back in 
2011-2017

> 
> > In fact, it's for this reason that some of our QML-based apps even
> > specify their runtime dependencies as build-time dependencies. This may
> > not be technically accurate, but it solves the problem by getting
> > packagers' attention when something fails to build.
> 
> I've seen that also fail as well, because then they get added to the
> build environment and still forgotten in the runtime environment. That
> just ensures we get a packaging build time for no real gain.
> 
> > Ultimately our goal is to ship quality software to users and I think
> > it's important to not lose sight of that.
> 
> I think everyone agrees on that goal.
> 
> /Sune
>  - who nowadays mostly has a upstream hat, but also has a old debian hat
>    hanging somewhere.