Remove files from debian/* that are unrelevant for this upstream repo

 * README and NEWS are very old and mostly plain wrong and not needed
 * Lintian-overrides are relevant only in actual Debian QA systems
 * watch file was plain wrong and anyway relevant only in downstream distros

debian/mariadb-client-10.1.files

@@ -12,7 +12,6 @@ usr/bin/mysqlreport
 usr/bin/mysqlshow
 usr/bin/mysqlslap
 usr/bin/mysql_waitpid
-usr/share/lintian/overrides/mariadb-client-10.1
 usr/share/man/man1/innotop.1
 usr/share/man/man1/mysqlaccess.1
 usr/share/man/man1/mysqladmin.1

debian/mariadb-server-10.1.README.Debian

@@ -1,82 +1,76 @@
 * MYSQL WON'T START OR STOP?:
 =============================
-You may never ever delete the special mysql user "debian-sys-maint". This
-user together with the credentials in /etc/mysql/debian.cnf are used by the
-init scripts to stop the server as they would require knowledge of the mysql
-root users password else.
-So in most of the times you can fix the situation by making sure that the
-debian.cnf file contains the right password, e.g. by setting a new one
-(remember to do a "flush privileges" then).
+You may never ever delete the mysql user "root". Although it has no password
+is set, the unix_auth plugin ensure that it can only be run locally as the root
+user. The credentials in /etc/mysql/debian.cnf specify the user are used by the
+init scripts to stop the server and perform logrotation. So in most of the
+time you can fix the situation by making sure that the /etc/mysql/debian.cnf
+file specifies the root user and no password.
+
+This used to be the debian-sys-maint user which is no longer used.
 
 * WHAT TO DO AFTER UPGRADES:
 ============================
 The privilege tables are automatically updated so all there is left is read
-the changelogs on dev.mysql.com to see if any changes affect custom apps.
+the release notes on https://mariadb.com/kb/en/release-notes/ to see if any
+changes affect custom apps.
 
 * WHAT TO DO AFTER INSTALLATION:
 ================================
 The MySQL manual describes certain steps to do at this stage in a separate
 chapter.  They are not necessary as the Debian packages does them
 automatically.
 
-The only thing that is left over for the admin is 
+The only thing that is left over for the admin is
  - setting the passwords
  - creating new users and databases
  - read the rest of this text
 
-* DOWNGRADING TO 4.0 or 4.1:
-============================
-Unsupported. Period.
-But if you do and get problems or make interesting experiences, mail me, it
-might help others.
-Ok, if you really want, I would recommend to "mysqldump --opt" all tables,
-then purge 4.1, delete /var/lib/mysql, install 4.0 and insert the dumps.  Be
-carefully, though, with the "mysql" table, you might not simply overwrite that
-one as the password for the mysql "debian-sys-maint" user is stored in
-/etc/mysql/debian.cnf and needed by /etc/init.d/ to start mysql and check if
-it's alive. 
-
-* SOME APPLICATION CAN NO LONGER CONNECT:
-=========================================
-This application is probably linked against libmysqlclient12 or below and
-somebody has created a mysql user with new-style passwords.
-The old_passwords=1 option in /etc/mysql/my.cnf might help. If not the
-application that inserted the user has to be changed or the application that
-tries to connect updated to libmysqlclient14 or -15.
-
 * NETWORKING:
 =============
 For security reasons, the Debian package has enabled networking only on the
 loop-back device using "bind-address" in /etc/mysql/my.cnf.  Check with
 "netstat -tlnp" where it is listening. If your connection is aborted
-immediately see if "mysqld: all" or similar is in /etc/hosts.allow and read
-hosts_access(5).
+immediately check your firewall rules or network routes.
 
 * WHERE IS THE DOCUMENTATION?:
 ==============================
-Unfortunately due to licensing restrictions, debian currently not able
-to provide the mysql-doc package in any format.  For the most up to date
-documentation, please go to http://dev.mysql.com/doc.
+https://mariadb.com/kb
 
 * PASSWORDS:
 ============
-It is strongly recommended to set a password for the mysql root user (which
-  /usr/bin/mysql -u root -D mysql -e "update user set password=password('new-password') where user='root'"
-  /usr/bin/mysql -u root -e "flush privileges"
-If you already had a password set add "-p" before "-u" to the lines above.
+It is strongly recommended you create an admin users for your database
+adminstration needs.
+
+If your your local unix account is the one you want to have local super user
+access on your database with you can create the following account that will
+only work for the local unix user connecting to the database locally.
+
+  sudo /usr/bin/mysql -e "GRANT ALL ON *.* TO '$USER'@'localhost' IDENTIFIED VIA unix_socket WITH GRANT OPTION"
+
+To create a local machine account username=USERNAME with a password:
+
+  sudo /usr/bin/mysql -e "GRANT ALL ON *.* TO 'USERNAME'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION"
+
+To create a USERNAME user with password 'password' admin user that can access
+the DB server over the network:
+
+  sudo /usr/bin/mysql -e "GRANT ALL ON *.* TO 'USERNAME'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION"
 
+Scripts should run as a user have have the required grants and be identified via unix_socket.
 
-If you are tired to type the password in every time or want to automate your
-scripts you can store it in the file $HOME/.my.cnf. It should be chmod 0600
-(-rw------- username username .my.cnf) to ensure that nobody else can read
-it.  Every other configuration parameter can be stored there, too. You will
-find an example below and more information in the MySQL manual in
-/usr/share/doc/mysql-doc or www.mysql.com.
+If you are too tired to type the password in every time and unix_socket auth
+doesn't suit your needs, you can store it in the file $HOME/.my.cnf. It should
+be chmod 0600 (-rw------- username username .my.cnf) to ensure that nobody else
+can read it.  Every other configuration parameter can be stored there, too.
 
-ATTENTION: It is necessary, that a .my.cnf from root always contains a "user"
+For more information in the MariaDB manual in/usr/share/doc/mariadb-doc or 
+https://mariadb.com/kb/en/configuring-mariadb-with-mycnf/.
+
+ATTENTION: It is necessary, that a ~/.my.cnf from root always contains a "user"
 line wherever there is a "password" line, else, the Debian maintenance
 scripts, that use /etc/mysql/debian.cnf, will use the username
-"debian-sys-maint" but the password that is in root's .my.cnf. Also note,
+"root" but the password that is in root's .my.cnf. Also note,
 that every change you make in the /root/.my.cnf will affect the mysql cron
 script, too.
 
@@ -85,19 +79,6 @@ script, too.
 	user		= your-mysql-username
 	password	= enter-your-good-new-password-here
 
-* BIG_ROWS FOR EVEN MORE ROWS IN A TABLE:
-=========================================
-If you ever run out of rows in a table there is the possibility of building
-the package with "-DBIG_ROWS" which, according to a MySQL employee on
-packagers@lists.mysql.com should lead to a 64bit row index (I guess > 2^32
-rows) but also to an approx. 5% performance loss.
-
-* BerkeleyDB Storage Engine
-===========================
-Support for BerkeleyDB has been removed in 5.1, and consequently both the
-have-bdb and skip-bdb configuration options will cause the server to fail. 
-Removing the options from /etc/mysql/my.cnf will fix this problem.
-
 * FURTHER NOTES ON REPLICATION
 ===============================
 If the MySQL server is acting as a replication slave, you should not
@@ -107,3 +88,19 @@ slave needs some of its temporary files to survive a machine restart so
 that it can replicate temporary tables or LOAD DATA INFILE operations. If
 files in the temporary file directory are lost when the server restarts,
 replication fails.
+
+* DOWNGRADING
+============================
+Unsupported. Period.
+
+You might get lucky downgrading a few minor versions without issued. Take a
+backup first. If you break it you get to keep both pieces. Do a restore from
+backup or upgrade to the previous version.
+
+If doing a major version downgrade, take a mysqldump/mydumpber consistent
+backup using the current version and reload after downgrading and purging
+existing databases.
+
+* BACKUPS
+============================
+Backups save jobs. Don't get caught without one.

debian/mariadb-server-10.1.files.in

@@ -58,7 +58,6 @@ usr/bin/wsrep_sst_xtrabackup-v2
 usr/share/doc/mariadb-server-10.1/mysqld.sym.gz
 usr/share/doc/mariadb-server-10.1/INFO_SRC
 usr/share/doc/mariadb-server-10.1/INFO_BIN
-usr/share/lintian/overrides/mariadb-server-10.1
 usr/share/man/man1/msql2mysql.1
 usr/share/man/man1/myisamchk.1
 usr/share/man/man1/myisam_ftdump.1

debian/mysql-common.files

@@ -1,3 +1,2 @@
 etc/mysql/my.cnf
 usr/share/mysql-common/internal-use-only
-usr/share/lintian/overrides/mysql-common

debian/rules

@@ -183,12 +183,6 @@ install: build
 	# mariadb-test
 	mv $(TMP)/usr/mysql-test	$(TMP)/usr/share/mysql
 
-	# lintian overrides
-	mkdir -p $(TMP)/usr/share/lintian/overrides/
-	cp debian/mysql-common.lintian-overrides      $(TMP)/usr/share/lintian/overrides/mysql-common
-	cp debian/mariadb-server-10.1.lintian-overrides $(TMP)/usr/share/lintian/overrides/mariadb-server-10.1
-	cp debian/mariadb-client-10.1.lintian-overrides $(TMP)/usr/share/lintian/overrides/mariadb-client-10.1
-
 	# For 5.0 -> 10.1 transition
 	d=$(TMP)/usr/share/mysql-common/internal-use-only/; \
 	mkdir -p $$d; \