When upgrading Qt, the packages will be built and merged one by one. However, since the merge of the new version of one Qt package, until all Qt packages have been upgraded, Qt applications will be unusable. This results in a very long downtime. I think Qt packages should be merged all at once, after all Qt packages have been built.
You're asking for a different package manager, and in further consequence a completely different distribution.
What I'm asking for is a feature in Portage. Not necessarily a different package manager.
Re-assigning to portage proj then, if they think they can give you a better answer.
How would Portage know that this arbitrary subset of packages should be merged to / together? I don't see how copying files around could ever be atomic, so there's always going to be a "downtime". I suppose it'd be theoretically possible to merge all packages to / all at once, but then every package everywhere would need to figure out how to build against dependencies in / and in PORTAGE_TMPDIR, so I don't see that as being very useful. I'm not sure there's anything anybody can do about this from Portage's perspective. You might be able to make the merges quicker by generating the binary packages elsewhere, but that's just a method to minimize the "downtime", not a fix.
Right, that's your actual Portage feature you can already utilise: Build in a chroot, merge binary packages only on your actual system.
That sounds like Qt failing to use SOVERSIONs correctly.
That's actually the case and openSUSE are patching it, but that is not nearly enough: https://build.opensuse.org/package/view_file/openSUSE:Factory/libqt5-qtbase/tell-the-truth-about-private-api.patch?expand=1
(In reply to Michał Górny from comment #6) > That sounds like Qt failing to use SOVERSIONs correctly. It's not about soversions--that would report "shared library ... not found" What I got is "Can't mix different versions of Qt" upon startup
(In reply to tusooa from comment #8) > (In reply to Michał Górny from comment #6) > > That sounds like Qt failing to use SOVERSIONs correctly. > > It's not about soversions--that would report "shared library ... not found" > It is, because if the SOVERSIONs were correct, the old ones would be loaded (and kept around by preserve-libs) until the rebuilds were done.
(In reply to Andreas Sturmlechner from comment #7) > That's actually the case and openSUSE are patching it, but that is not > nearly enough: > > https://build.opensuse.org/package/view_file/openSUSE:Factory/libqt5-qtbase/ > tell-the-truth-about-private-api.patch?expand=1 I wonder why they do it if it's not enough. I guess it's a purity thing but they don't notice that it's insufficient because they have binary packages to install which are quick.
(In reply to Sam James from comment #9) > (In reply to tusooa from comment #8) > > (In reply to Michał Górny from comment #6) > > > That sounds like Qt failing to use SOVERSIONs correctly. > > > > It's not about soversions--that would report "shared library ... not found" > > > > It is, because if the SOVERSIONs were correct, the old ones would be loaded > (and kept around by preserve-libs) until the rebuilds were done. Yes and no. It seems that qt applications are fine without rebuilds after some upgrades of Qt (Qt apps don't need to be rebuilt against new Qt version) but Components of Qt asks for the same version of each other (Qt libraries need to be rebuilt against other components). Now I'm wondering why we are separating out the components in different packages instead of, say, combine them into a single package where the components can be chosen by USE flags.
(In reply to tusooa from comment #11) > (In reply to Sam James from comment #9) > > (In reply to tusooa from comment #8) > > > (In reply to Michał Górny from comment #6) > > > > That sounds like Qt failing to use SOVERSIONs correctly. > > > > > > It's not about soversions--that would report "shared library ... not found" > > > > > > > It is, because if the SOVERSIONs were correct, the old ones would be loaded > > (and kept around by preserve-libs) until the rebuilds were done. > > Yes and no. It seems that qt applications are fine without rebuilds after > some upgrades of Qt (Qt apps don't need to be rebuilt against new Qt > version) but Components of Qt asks for the same version of each other (Qt > libraries need to be rebuilt against other components). > Oh right, sorry, yes. > Now I'm wondering why we are separating out the components in different > packages instead of, say, combine them into a single package where the > components can be chosen by USE flags. Because it's quicker to build individual components without rebuilding the whole thing and it allows refined dependencies (can just pull in the extra dep without requiring a USE flag change).
