Bug#745135: RFS: mariadb-10.0/10.0.10-1 [ITP] -- Latest version of worlds most popular non-Oracle database
> Well, goal of all packages should be that they should be as lintian
> clean as possible. As you said, 5.5 is in the archives, I say 10.0 is
> not; for many DDs lintian cleaness is a requirement for sponsoring.
> (Also note that lintian evolves and therefor will report now issues that
> where not detected at that time 5.5 was introduced)
OK, I am determined to make both 10.0 and 5.5 as Lintian clean as
possible now, including even spelling errors.
> BTW, when you iterate, can you always upload to mentors afterwards?
Yes, I'll do so. The latest version is uploding now and soon visible
at http://mentors.debian.net/package/mariadb-10.0
> Ok, browsing the source I have the impression that the source of it is
> indeed maridb-5.5. (Some residual references on it). So I suggest you
> review every single file in your debian directory.
>
> I saw already some problems (random ordering):
> -> d/control builds same binary packages as mdb-5.5. That won't work.
MariaDB 10.0 is intended to supersede 5.5, and in future the
mariadb-common, libmariadbclient etc packages are supposed to come
from 10.0 source package. Should I maybe disable them at this stage?
> -> d/copyright needs to be updated, please use dep5 format
The format does follow http://dep.debian.net/deps/dep5/ and I now
fixed the 5.5 typos in it. I also grepped debian/* for 5.5. to make
sure there are no other 5.5 typos.
> -> d/patches please add dep3 compliant headers (using quilt header -e
> --dep3)
I have now used the '## DP:' markup as Lintian suggested, but I will
change the patches I've done myself to dep3 format now.
> -> some d/patches are fuzzy, needs to be refreshed
What does this mean? That the line numbers don't match? What tool do
you use to detect fuzzyness?
> -> I saw in some postinst a call to ldconfig. This is a policy violation
> the way it is. However, debhelper will take care of it, so remove this
> postinst script. e.g libmariadbclient18.postinst but there are more
> postinsts to be checked. Probably you can just remove the postinstse
> here.
MySQL 5.6 does not seem to use neither of these postinstalls, so I
removed them. Will later run more tests to make sure there are no
regressions. But to be honest I don't fully understand what they do,
and that is the reason I was afraid to remove them earlier when I read
about ldconfig and suspected they might be obsolete.
> -> d/changelog for new packages is just "Initial Upload (Closes:
> #ITP-Bug)
Done.
> -> (personal taste) please review if d/rules can be shortened and
> converted to short debhelper formart.. Some rules look a little weird,
> too. For example, the ha_cassandra.so detection: It is there (due to
> B-D) or not. And, the change to the *.install file is nowhere undone.
Yes, this is a hack. But I think it is the least ugly of all
solutions. I added more comments to d/rules to describe it.
> (There is no B-D on libthrift.dev on d/control)
Libthrift-dev is not in Debian, so I cannot depend on it, but hope to
use the same Debian packaging and rules file to build MariaDB 10.0 on
an environment with manually installed libthrift-dev.
> The manpages can also be installed by debhelper....
> (I you feel so, I really suggest to switch to short debhelper and then
> add the really required pieces)
I use the same format as
http://anonscm.debian.org/gitweb/?p=pkg-mysql/mysql-5.6.git;a=blob;f=debian/rules
to stay a bit more compatible. Isn't this format already the short
debhelper format, does some other debhelper format exist?
> -> There are many conflicts against mysql. Are they really needed?
> It would be best if they could life in coexistance, at least
> co-installable.
Yes, only the -common and shared libs are co-installable, the other
stuff is not. This part has been extensively reviewed in multiple
discussions with all the MySQL variant packagers and this is how all
the virtual-mysql-packages are now defined. That does not mean it is
perfect, but I don't think there is any other solution at the moment.
> (Stopping here as running out of time)
Ok, thanks again for your feedback on the other details nobody else so
far noticed!
--
Check out our blog at http://seravo.fi/blog
and follow @ottokekalainen
Reply to: