Re: Keeping the Qt5 stack together: some ideas
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
signature.asc
Description: OpenPGP digital signature
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Keeping the Qt5 stack together: some ideas
Hi everyone, > So basically we need a way to ensure the Qt 5 stack gets tied together. I can > think in two possible ways of doing it: > > 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. > > 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. > > With this solution apps building against qt 5.5.1 which use symbols < 5.5.1 > should migrate whenever they are ready, although it's not clear to me we > really want this. On the other hand it let us tie up arch:all packages. > > So before rushing I would like to know if someone sees something I don't here. > > I somehow like option b more than a, but I would be glad to be show that a is > superior (if it is). How about more simple solution? c) Provide special empty package with current Qt5 version and add it into dependencies of all Qt5-related packages with strict or non-strict requirements for a version depending on the situation. Best regards, Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Keeping the Qt5 stack together: some ideas
On Thursday 29 October 2015 17:46:12 Lisandro Damián Nicanor Pérez Meyer wrote: > - it turned out to not use any symbol from qtbase >= 5.5.x, so after being > built it's dependencies got satisfied with testing's ones. > > Except it broke. > > 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). I think this is the entire purpose why b-d-p was invented, so I think we should use that. > We can't use this solution for arch:all packages. I don't think that's a major issue for arch:all packages /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Keeping the Qt5 stack together: some ideas
On Friday 30 October 2015 11:36:14 Boris Pek wrote: > Hi everyone, [snip] > How about more simple solution? > > c) Provide special empty package with current Qt5 version and add it into >dependencies of all Qt5-related packages with strict or non-strict >requirements for a version depending on the situation. This is more or less (b) by creating an empty package. It's an alternative, indeed. -- "La política es una actividad noble. Hay que revalorizarla, ejerciéndola con vocación y una dedicación que exige testimonio, martirio, o sea, morir por el bien común." Padre Bergoglio - http://www.lanacion.com.ar/1153060 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Keeping the Qt5 stack together: some ideas
Well, I think most of you preferred the B-D-P way both here and on IRC, so let's call it consensus :) Will get to it in the next upload, whenever that happens. Thanks *a lot* everyone for the feedback :) -- "With great power comes great responsibility." Peter Parker's uncle. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Keeping the Qt5 stack together: some ideas
With the Qt 5.5.1 transition we hit a problem we never had before: src:qtx11extras-opensource-src migrated to testing before the rest of the Qt 5.5.1 stack. The reasons are simple: - it does not ends up depending on any qt5 internal so it doesn't has a dependency upon qtbase-abi-x-y-z - it turned out to not use any symbol from qtbase >= 5.5.x, so after being built it's dependencies got satisfied with testing's ones. Except it broke. So basically we need a way to ensure the Qt 5 stack gets tied together. I can think in two possible ways of doing it: 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. 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. With this solution apps building against qt 5.5.1 which use symbols < 5.5.1 should migrate whenever they are ready, although it's not clear to me we really want this. On the other hand it let us tie up arch:all packages. So before rushing I would like to know if someone sees something I don't here. I somehow like option b more than a, but I would be glad to be show that a is superior (if it is). Kinds regards, Lisandro. -- "With great power comes great responsibility." Peter Parker's uncle. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
