[Tinkerphones] [Gta04-owner] QtMoko2 again...

H. Nikolaus Schaller hns at goldelico.com
Thu Oct 26 15:18:13 CEST 2017


> Am 26.10.2017 um 11:11 schrieb Jonas Smedegaard <jonas at jones.dk>:
> Quoting H. Nikolaus Schaller (2017-10-26 07:05:10)
>>> Am 25.10.2017 um 19:32 schrieb Jonas Smedegaard <jonas at jones.dk>:
>>> Quoting H. Nikolaus Schaller (2017-10-25 17:44:50)
>>>> Back to the original problem: I had not expected that there is a 
>>>> need for a configure-make-install. Since we are fully Debian.
>>> How do you mean configure-build-install isn't needed? QtMoko is 
>>> compiled code, so will need to be compiled.
>> Indeed.
>> But you shouldn't have to to type configure & make to start the 
>> dpkg-buildpackage wrapped by a makefile.
>> The dpkg-buildpackage of course must do a configure & make for the 
>> source tree, but hide that from the user.
>> IMHO, something is done here upside down.
>> My initial mistake was to assume that I can directly call 
>> dpkg-buildpackage after unpacking the source tree. It turned out that 
>> this does not work. At least not without modifications.
> If you expect source to be a Debian source package¹

not initially, but as a goal.

> then I agree it must 
> be be buildable by a) simply unpacking it (dpkg-source -x *.dsc), b) cd 
> into root of unpacked source tree, and c) build it (dpkg-buildpackage).
> But a large project involving embedded (likely multiple interlinked) 
> libraries cannot sensibly² be organized as a single(!) Debian source 
> package - each library should be a separate source package, built and 
> tested and packaged and versioned on its own.

Well, AFAIR it is possible to specify a source package that builds
multiple binary packages.

> I thought that your labeling it "upside down" meant that you think it 
> should be adjusted to be able to compile with a single dpkg-buildpackage 
> call.

a single call for qtmoko: yes.

But there are usually build-dependencies which means that other packages
are to be built first. So I expect that all libs and apps are dependents
of a qtmoko meta package.

If they share the same source package or tarball doesn't matter much.

>  I disagree with that: I believe that the sensible way to turn 
> such a set of essentially multiple sources is to unentangle those into 
> multiple Debian source packages and build each of those separately.

In the worst case the build host needs to have much space to keep all
the copies of the monolithic source tree - and just compiled tiny bits
of it.

> If untentangling into multiple Debian source packages was also what you 
> talk about I do believe that untentangling into multiple Debian source 
> packages is what Joshua intend to (eventually, when better understood) 
> reach at.  If that is also what you are talking about above, then I 
> simply suggest to not label it as "upside down" which can be 
> misunderstood as the _build_ routines_ need fixing when really it is 
> more fundamentally the _source organization_ which need fixing (too).
> A more descriptive labeling would in my opinion be "a big mess".

Well, that is not usually my vocabulary, but you are right :)

> ¹ Source format "1.0" is upstream tarball + Debian diff + dsc file, and 
> source format "3.0 (quilt)" is upstream tarball + Debian tarball + dsc 
> file.
> ² Indeed, Chromium is *not* a sensibly organized source package!
>>>> It should even be possible to use apt-source -b - if we have proper 
>>>> source packages. So it looks as if the build architecture of QtMoko 
>>>> is upside down...
>>>> Maybe it is historical since this is still Squeeze and Wheezy code 
>>>> and multiarch wasn't complete back then. On Jessie or Stretch I 
>>>> think it could be much simpler if the debian/rules are updated.
>>> I believe the reason QtMoko build routines fit badly with Debian 
>>> style of packaging is that it does not use existing shared Qt 
>>> libraries but instead embeds its own fork of Qt optimized for 
>>> embedded devices: https://en.wikipedia.org/wiki/Qt_Extended
>> It could be a renowned Debian citizen if it would not embed it but 
>> just package and provide the special QtE libraries and then just use 
>> the -dev version for dpkg-building the launcher, dialer, etc. This is 
>> what Josua is working on:
>> http://git.goldelico.com/?p=qtmoko2-qte.git;a=summary
> I guess that this:
>   "if it would not embed it"
> expands to this:
>   "if QtMoko project would not embed QtE libraries"
> and then we agree - except for the word "just": Joshua reports that 
> there are trouble unentangling them because their interdependency seems 
> to form a circular graph.


More information about the Community mailing list