Now we check if a dependency is available and not just if older versions
are available. Also use correct name of libcrack2 to actually detect it.
Use sed to inject dependency at the end of the dependency list.
Otherwise keep the control line clean and parseable by Debian tools.
- All build-depends should be in one place.
- Library packages should depend on their main package using strict version.
- Most packages should depend on the misc variable, so that debhelper
can fill in it with various calculated dependencies automatically.
- All packages using dynamic libraries should depend on the shlibs variable
to include shared libraries as dependencies automatically.
- Essential tools like bsdutils, grep and tar shall not be defined in vain.
Make dependency on mysql-common package in debian/control
versioned to force that it is installed together with the other
mariadb-* packages. This ensures that the init.d and systemd
files for MariaDB mysqld are the ones from MariaDB.org repos.
This should make the provides/breaks/replaces/conflicts lines
work properly when upgrading from mysql-5.6 to mariadb-packages.
Conflicts:
debian/control
The only difference between the files was the Debian standards
line by one micro version. There was no logical motivation why
there was separate control file for Debian and Ubuntu.
The new debian/control file lives directly at the correct location
and has the correct contents.
Modify autobake.sh to take into account new control file location.
This reverts commit 6bd94cf542.
Without galera as a compulsory dependency, test suite will not pass
due to failing:
wsrep.pool_of_threads wsrep.binlog_format wsrep.mdev_6832 wsrep.mdev_7798
Plus minor other fixes to debian/control file, wrap-and-sort,
versioned mariadb-common dependency etc. All changes based on
comparison with mariadb-10.0 packaging in official Debian
repositories.
Having galera-3 as a Depends stops installation of proceeding
on systems where package galera-3 is not available. The server
can run fine withouth galera enabled, therefore a more slack
relationship is more appropriate.
* dpatch cannot be removed yet, as packaging standard isn't updated
* we don't want to remove libssl at all, as in upstream we rather
use system provided OpenSSL than bundled, non-system updated and
less commonly trusted YaSSL
* keep versioned dependencies, they might prove helpful when building
for multiple distros and releases
For tracking purposes this step is committed first before
the unnecessary dependencies are trimmed away.
libpcre3-dev (>= 2:8.35-3.2~) is however omitted (compared to
downstream Debian packaging) as it is not available in precise
and we don't want to break builds on precise yet.
Use the slightly better Ubuntu version in both Ubuntu and
Debian and latest versions of Debian don't have problems
with AppArmor files included in packaging.
