Keeping the Qt5 stack together: some ideas
Dmitry Shachnev
mitya57 at debian.org
Fri Oct 30 06:42:56 UTC 2015
Hi all,
On Thu, 29 Oct 2015 17:46:12 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> a) Suggested by Adam Majer and improved by Felix Geyer: if package A gets
> built against any qtbase x.y.z lib make it depend upon the version used to get
> the package built by using Build-Depends-Package from deb-symbols(5).
>
> With this solution we ensure that the libs gets tied together, but also apps
> rebuilt against this version. I don't know if there is a real use case for
> apps migrating faster than Qt itself except for simplifying transitions (and
> we still don't know how safe that could be).
>
> We can't use this solution for arch:all packages.
This will help us keeping the stack together in only one direction: in theory
it can happen that i.e. qtbase migrates but qtx11extras does not.
If we want to tighten the dependencies in both directions, we can just write
some debian/rules code that will add this to ${qt5:Depends}:
libqt5core5a (>= 5.x.y~), libqt5core5a (<< 5.x.(y+1)~)
where x and y are extracted from upstream version number (i.e. from parsing
debian/changelog). Then we will can make all arch-dependent packages depend
on ${qt5:Depends}. (This is similar to what GNOME does, IIRC.)
Re arch:all packages, we don't really have many of them. We have docs, but there
is no need to tighten dependencies for docs packages.
If there is a qtfoo library that needs a qtfoo-common package of exactly the
same version, it can just depend on qtfoo-common (= ${upstream:Version}). So
there is really no problem with arch:all packages.
> b) Somehow (I think KDE does this) create a variable to be used in
> debian/control so it get substituted at build time against whatever we set up
> in, let's say, qtbase. We can use that variable in the whole Qt stack
> including source packages that build arch: all binaries like translations.
> Docs should not depend on binaries so maybe we need something different there.
The problem is that we do not have a common arch:all package that everything
should depend on. qttranslations5-l10n will not work because it is not in qtbase
and it's optional (we don't really want to depend on translations).
--
Dmitry Shachnev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20151030/ce44005f/attachment.sig>
More information about the pkg-kde-talk
mailing list