Don't mark dependency packages as manually installed

[native-api]

This was causing apt-get to refuse to install MariaDB unless one specifies all its corresponding dependencies on the command line, too.

What is the problem that this PR is trying to fix?

https://travis-ci.community/t/failures-installing-mariadb-10-2-on-xenial

What approach did you choose and why?

Fixing the problem at its source

How can you make sure the change works as expected?

The following should not cause apt install errors due to package conflict (but may cause an unrelated error on configuration stage, MariaDB addon is supposed to workaround it with its extra logic):

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xf1656f24c74cd1d8
sudo apt-add-repository 'deb http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu xenial main'
sudo apt update
sudo apt-get install -y -o Debug::pkgProblemResolver=yes -o Dpkg::Options::=--force-confnew mariadb-server-10.1

Would you like any additional feedback?

[morozov]

@travis-ci, any chance this patch gets some attention? The issue prevents the projects that build against MariaDB 10.1 from migrating from Trusty.

[morozov]

@native-api while this proposal is in review, could you suggest a workaround that could be applied in a project's travis.yml file and effectively implemented the same logic that this patch does? E.g. a series of apt commands called before MariaDB is installed.

[native-api]

@morozov A workaround is to manually run the same commands that the addon does but select all 4 MariaDB packages as I did in https://travis-ci.org/native-api/test_travis/builds/593807343#L221.

[morozov]

@native-api but didn't the build where you used the workaround fail?

[native-api]

@morozov That's because the addon runs a number of other commands, too, that I didn't. I was only testing package conflict resolution.

[morozov]

I see. I'm trying to migrate from Trusty to Xenial or Bionic and keep testing against several MariaDB versions (including 10.1).

So practically, this workaround doesn't seem usable for me since your build failed with the message:

Status: "MariaDB server is down"

Even if the conflict was solved, there are other remaining issues that would still block the migration.