At home I went back to using stable, so I would not mind having Qt5
backported in case I want to test some application against it, but
with the Qt SDK is not a big deal, since it's easy to have a recent
Qt5 without much hassle, and build stuff.

However, at work I also use Debian stable, and we intend to deploy a
Qt-based application (only Core and Network for now) to an "embedded"
that is large enough to run a full distro (no need to go to Emdebian
for now).

The thing is, in our previous project we built a trimmed down Qt 4.8,
but the process of deploying it was terrible, copying all the files
manually. I would like to improve that, since a packaged Qt is
convenient for several reasons (no PATH or LD_LIBRARY_PATH to find
qmake or the

My packaging knowledge is small (and rusty), and I haven't spent much
time looking at the sources, but I would like to start by asking you
what do you think about having in the same tree a packaging that would
allow a backported Qt and/or a build with some reduced options (e.g.
not all SQL drivers).

For now I've toyed with the sources that I got from Sid, and I've
compiled attempting to change some flag with export
extra_configure_opts='-no-icu' for example (just for trying, and
because we don't actually need ICU). It seems the packages built
decently, but I will have stuff to polish (for example, the dependency
on qtchooser).

I guess it will be possible that the only way to work around some
issues is make a different branch for the changes neede for a
backport. What's your opinion on that? Would you prefer that I kept
such a branch in pkg-kde, or should I keep it for myself in some other

Oh, one more thing. Is something shared or coordinated with the
ubuntu/kubuntu people? In a quick search I don't see them in the
shortlog. :-(

Thank you!

Alejandro Exojo Piqueras

ModpoW, S.L.
Technova LaSalle | Sant Joan de la Salle 42 | 08022 Barcelona | www.modpow.es


Reply via email to