Qt will not static compile SQLIte

[Roland Hughes]

When you attempt to static compile in SQLite (use -qt-sql-sqlite instead of -plugin-sql-sqlite) the build is unsuccessful.

Debian.rules around source line 99 you find the following:
             -plugin-sql-mysql \
             -plugin-sql-odbc \
             -plugin-sql-psql \
             -qt-sql-sqlite \
             -plugin-sql-sqlite2 \
             -plugin-sql-tds \
             -system-sqlite \

stltest.cpp: In function ‘int main()’:
stltest.cpp:145: warning: unused variable ‘n’
alsatest.cpp:47: warning: unused parameter ‘argc’
alsatest.cpp:47: warning: unused parameter ‘argv’
cat: .qmake.vars: No such file or directory
 fakeroot debian/rules binary
potential duplicate alias detected: 'widget.png'
cp: cannot stat `debian/tmp/usr/lib/qt4/plugins/sqldrivers/libqsqlite.so': No such file or directory
dh_install: cp -a debian/tmp/usr/lib/qt4/plugins/sqldrivers/libqsqlite.so debian/libqt4-sql-sqlite//usr/lib/qt4/plugins/sqldrivers/ returned exit code 1
make[1]: *** [override_dh_install] Error 2
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
roland@roland-Generic-Desktop1:/save_sets/rebuild/qt4-x11-4.7.0$

roland@roland-Generic-Desktop1:~$ lsb_release -rd
Description: Ubuntu 10.10
Release: 10.10

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: libqt4-sql-sqlite 4:4.7.0-0ubuntu4.2 [modified: usr/lib/qt4/plugins/sqldrivers/libqsqlite.so]
ProcVersionSignature: Ubuntu 2.6.35-27.48-generic 2.6.35.11
Uname: Linux 2.6.35-27-generic x86_64
Architecture: amd64
Date: Tue Mar 8 11:56:20 2011
InstallationMedia: Kubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
ProcEnviron:
 LANGUAGE=
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: qt4-x11

[Terence Simpson (tsimpson)]

If you have changed which files are generated, for instance by changing the configure options, then you can't use dpkg-buildpackage (or debuild) without changing the various *.install files. You can still compile and manually, but you will need to edit the various packaging files if you want to build .debs

[Roland Hughes (original-seasoned-geek)]

Well,

I followed the instructions posted EXPLICITLY and I can tell you that the various *.install things were not mentioned in any way shape or form for modification.

So

this is a bug.

You EITHER fix the *.install packages to be CONFIG aware (as they should be) OR you fix the documentation.

It's still a bug.

[Jonathan Thomas (echidnaman)]

.install files are meant to be a static manifest of the files resulting from a build. A mechanism doesn't exist in the Debian packaging system to make the .install files aware of configuration. The only thing that comes even remotely close is wildcards such as /usr/share/* to install everything installed to /usr/share to a package.

Which documentation are you referring to?
If you change the files built when dpkg is run, you must also modify the .install files.

[Roland Hughes (original-seasoned-geek)]

>.install files are meant to be a static manifest of the files resulting
>from a build. A mechanism doesn't exist in the Debian packaging system
>to make the .install files aware of configuration.

that statement is quite honestly pure ka-ka.

In debian/rules on or about listing line 144 "you" (whoever you
is) ./config.status which happens to contain whatever was passed to
configure.

#!/bin/sh
if [ "$#" -gt 0 ]; then
  LDFLAGS='-Wl,-Bsymbolic-functions' CXXFLAGS='-g -O2' CFLAGS='-g
-O2' /save_sets/rebuild/qt4-x11-4.7.0/configure -confirm-license
-prefix /usr -bindir /usr/bin -libdir /usr/lib
-docdir /usr/share/qt4/doc -headerdir /usr/include/qt4
-datadir /usr/share/qt4 -plugindir /usr/lib/qt4/plugins
-importdir /usr/lib/qt4/imports
-translationdir /usr/share/qt4/translations -sysconfdir /etc/xdg
-demosdir /usr/lib/qt4/demos -examplesdir /usr/lib/qt4/examples
-opensource -fast -plugin-sql-mysql -plugin-sql-odbc -plugin-sql-psql
-qt-sql-sqlite -plugin-sql-sqlite2 -plugin-sql-tds -system-sqlite
-xmlpatterns -no-multimedia -audio-backend -no-phonon -no-phonon-backend
-svg -no-webkit -script -scripttools -platform linux-g++-64 -system-zlib
-qt-gif -system-libtiff -system-libpng -system-libjpeg -no-rpath
-optimized-qmake -dbus -no-separate-debug-info -verbose -gtkstyle
-system-nas-sound -lfontconfig -I/usr/include/freetype2 -qvfb
-plugin-sql-ibase "$@"
else
  LDFLAGS='-Wl,-Bsymbolic-functions' CXXFLAGS='-g -O2' CFLAGS='-g
-O2' /save_sets/rebuild/qt4-x11-4.7.0/configure -confirm-license
-prefix /usr -bindir /usr/bin -libdir /usr/lib
-docdir /usr/share/qt4/doc -headerdir /usr/include/qt4
-datadir /usr/share/qt4 -plugindir /usr/lib/qt4/plugins
-importdir /usr/lib/qt4/imports
-translationdir /usr/share/qt4/translations -sysconfdir /etc/xdg
-demosdir /usr/lib/qt4/demos -examplesdir /usr/lib/qt4/examples
-opensource -fast -plugin-sql-mysql -plugin-sql-odbc -plugin-sql-psql
-qt-sql-sqlite -plugin-sql-sqlite2 -plugin-sql-tds -system-sqlite
-xmlpatterns -no-multimedia -audio-backend -no-phonon -no-phonon-backend
-svg -no-webkit -script -scripttools -platform linux-g++-64 -system-zlib
-qt-gif -system-libtiff -system-libpng -system-libjpeg -no-rpath
-optimized-qmake -dbus -no-separate-debug-info -verbose -gtkstyle
-system-nas-sound -lfontconfig -I/usr/include/freetype2 -qvfb
-plugin-sql-ibase
fi

at listing line 27 we find:

ibase_architectures := i386 kfreebsd-i386 kfreebsd-amd64 knetbsd-i386
netbsd-i386 amd64 sparc powerpc
#ibase_architectures := none
ifeq ($(DEB_HOST_ARCH),$(findstring $(DEB_HOST_ARCH),
$(ibase_architectures)))
 extra_configure_opts += -plugin-sql-ibase
else
 extra_configure_opts += -no-sql-ibase
endif

so we know that regular if statements work in this rules file.

This means that at any point _after_ line 221:
override_dh_auto_install:
ifeq ("-qt-sql-sqlite", $(findstring "-qt-sql-sqlite", $(LDFLAGS)))
  rm debian/libqt4-sql-sqlite.install
fi

perhaps you just want to echo an empty file instead of the one liner
that is there. I don't code script often so syntax could be off a bit,
but, there are only a handful of config qualifiers which convert a
plugin to a static object and there is no reason the debian rules file
cannot automagic...

[Terence Simpson (tsimpson)]

the files under debian/ are used specifically to create the .debs that are distributed in (K)Ubuntu and Debian, which does not use the static plugins.
You are doing something custom, and so you need to work out how to make it do what you want. This is no issues with the current status of the debian/rules or the debian/*.install files, as is evident by the fact that our packages successfully build.

[Jonathan Thomas (echidnaman)]

We can't possibly foresee what files will be installed for every combination of compile flags and support them in case somebody wants to customize the package. Once you customize a package, making sure it builds is entirely in your hands. If you want to make modifications to how things you are compiled during a package build, you could do fancy things in debian/rules. Go right ahead, but it's not our bug if your modifications don't build.

On solving your particular issue, if you're compiling SQLite statically and not building the plugin, you probably just need to disable the SQLite plugin package.

[Roland Hughes (original-seasoned-geek)]

There are only a handful of options which change the actual number of
files created.

These are well documented.

There is no need for you to "forsee" only to RTFM.

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net

No U.S. troops have ever lost their lives defending our ethanol
reserves.

On Wed, 2011-03-09 at 01:06 +0000, Jonathan Thomas wrote:

> We can't possibly foresee what files will be installed for every
> combination of compile flags and support them in case somebody wants to
> customize the package. Once you customize a package, making sure it
> builds is entirely in your hands. If you want to make modifications to
> how things you are compiled during a package build, you could do fancy
> things in debian/rules. Go right ahead, but it's not our bug if your
> modifications don't build.
>
> On solving your particular issue, if you're compiling SQLite statically
> and not building the plugin, you probably just need to disable the
> SQLite plugin package.
>

[Roland Hughes (original-seasoned-geek)]

This is a maintainer issue.

RTFM.

There is an extremely limited number of configuration switches which change the number of files created.

This is an education issue with the "support" team, nothing more.

[Jonathan Thomas (echidnaman)]

> This is a maintainer issue.
Our packages compile fine. You did not make enough changes for your modifications to actually work.

> RTFM.
A pretty bold statement, for somebody who cannot produce packages that actually build.

> There is an extremely limited number of configuration switches which change the number of files created.
Even so, we do not care about these as we do not distribute packages with these config switches. It would add more complexity to the debian/rules file, and more places for things to go wrong.

> This is an education issue with the "support" team, nothing more.
This is a bug tracker for software. If you have questions about how to package applications for Debian/Ubuntu, you can find a number of people who can help you in the #ubuntu-motu IRC channel on Freenode IRC. I should note that I also offered a solution at the end of comment #7 for the bug in your packaging.

[Roland Hughes (original-seasoned-geek)]

> This is an education issue with the "support" team, nothing more.

> This is a bug tracker for software. If you have questions about how to package applications for Debian/Ubuntu, you can find a number of people who can help you in the #ubuntu-motu IRC channel on Freenode IRC. I should note that I also offered a solution at the end of comment #7 for the bug in your packaging.
>

and this is a bug brought on mostly because people think it will look good to have "package a" maintaner on their resume as long as they only have to produce Microsoft quality work. It compiled one time, the first screen came up, ship it.

I have provided you the if statement which needs to be in Debian rules. You need to replicate that once for each -qt-sql-<database> configuration switch. That's it.

If you really think you will be able to continue this level of non-support now that ubuntu is adoption Qt instead of Gtk+ for it's standard development library, you have another thing coming. The bulk of those "applications" Ubuntu wants to bring in require reliable single database compilation, mostly SQLite, but many require compile in/embedded mysql.

You offered an unreliable hack. I offered you the actual code.

ifeq ("-qt-sql-sqlite ", $(findstring "-qt-sql-sqlite ", $(LDFLAGS)))
  rm debian/libqt4-sql-sqlite.install
fi

ifeq ("-qt-sql-mysql", $(findstring "-qt-sql-mysql", $(LDFLAGS)))
  rm debian/libqt4-sql-mysql.install
fi

ifeq ("-qt-sql-odbc", $(findstring "-qt-sql-odbc", $(LDFLAGS)))
  rm debian/libqt4-sql-odbc.install
fi

ifeq ("-qt-sql-psql", $(findstring "-qt-sql-psql", $(LDFLAGS)))
  rm debian/libqt4-sql-psql.install
fi

ifeq ("-qt-sql-tds", $(findstring "-qt-sql-tds", $(LDFLAGS)))
  rm debian/libqt4-sql-tds.install
fi

ifeq ("-qt-sql-sqlite2", $(findstring "-qt-sql-sqlite2", $(LDFLAGS)))
  rm debian/libqt4-sql-sqlite2.install
fi

And don't forget the " " at the end of sqlite or you can get a false
match with sqlite2 thanks to that backward compatibility issue.

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net

No U.S. troops have ever lost their lives defending our ethanol
reserves.

On Wed, 2011-03-09 at 05:05 +0000, Jonathan Thomas wrote:

> > This is a maintainer issue.
> Our packages compile fine. You did not make enough changes for your modifications to actually work.
>
> > RTFM.
> A pretty bold statement, for somebody who cannot produce packages that actually build.
>
> > There is an extremely limited number of configuration switches which change the number of files created.
> Even so, we do not care about these as we do not distribute packages with these config switches. It would add more complexity to the debian/rules file, and more places for things to go wrong.
>
> > This is an education issue with the "support" team, nothing more.
> This is a bug tracker for software. If you have questions about how to package applications for Debian/Ubuntu, you can find a number of people who can help you in the #ubuntu-motu IRC channel on Freenode IRC. I should note that I also offered a solution at the end of comment #7 for the bug in your packaging.
>

[Terence Simpson (tsimpson)]

Even if we could write the code for every possible combination of configure options, we simply aren't going to.
*No* other package does this either, by the way.

[Terence Simpson (tsimpson)]

Oh, and $(LDFLAGS) will never contain any of those strings you're searching for either, so the code you wrote will fail anyway

[Felix Geyer (debfx)]

Please stop reopening this bug report.

If you want to build Qt with different configure options it's up to you to make the package work.
We won't support that in the Ubuntu package.

[Harald Sitter (apachelogger)]

Hello Roland.

My name is Harald and I am core developer of Ubuntu.

Regarding the suggested changes I have to agree with the previous commenters. The way the package is built is exactly according to the Debian Policy Manual [1] which defines precisely what a good and reliable package should look like and how it should behave and integrate in the surrounding system.

In comment #3 [2] you are referring to documentation that you apparently followed to create the package. I would very much like to know where I may find this, as it is (obviously) incorrect. Also the Ubuntu project generally does not encourage building own packages to replace official ones, as this prevents any official support of any kind.
In particular at the point where you create your own package you become maintainer of that altered package and neither the Ubuntu community nor Canonical are in any way responsible for the resulting package(s) (most importantly they will not receive security updates obviously).

In that context I might also direct your attention to point 4.9 [3] of the Debian Policy Manual which outlines the behavior of a correct and proper debian/rules file. In particular you might want to read the part about the clean target.

If I may quote just a part of it:
"This [the clean target] must undo any effects that the build and binary targets may have had [...]"

Due to this the change you explicitly proposed is in direct violation of the Debian Policy Manual and could not possibly be included at any rate. By deleting a file in the debian/ directory it is gone forever, meaning that after one build, executing the clean target will not put the source package back into its original state. This is absolutely unacceptable behavior as I am sure you will understand.

As for the need of change in general and the modifications you requested in particular. As I already mentioned the package in its current state is valid and a result of application of sound and proven engineering principles for Makefiles in general and debian/rules files in particular. The changes you proposed introduce maintenance overhead and increase the overall code base, making it essentially more error prone. Primarily however the changes do not have any positive affect (or any for that matter) on the Qt packages in Ubuntu as those are, and also will be in the future, built with plugins rather than static binaries. Surely you are aware of the implications that static compilation has with regards to maintenance, especially in the context of security. It is exactly those implications that make it less than desirable to have static compiled parts anywhere in the system.

I do however acknowledge your desire for this kind of functional and propose the following.
Since your proposed changes do not bring any additional value to the Ubuntu binary packages of Qt the additional code and logic required would introduce overhead in the assurance of various software quality attributes, and is thus not fit for inclusion. However if you were to compensate for the introduced overhead I am reasonably sure an acceptable solution could be reached.

You can either enter a contract with Canonical [4...