Bug#745135: RFS: mariadb-10.0/10.0.10-1 [ITP] -- Latest version of worlds most popular non-Oracle database
Am Samstag, den 19.04.2014, 10:24 +0300 schrieb Otto Kekäläinen:
> Hello Tobias,
>
> Thanks for looking into this. My comments:
>
>
> 2014-04-18 15:12 GMT+03:00 Tobias Frost <tobi@coldtobi.de>:
> > Hallo Otto,
> >
> > (disclaimer: I cannot sponsor it, I'm not a DD)
>
> You still help me improve the quality of the package and mentor me
> mentally, so thanks anyway!
Well, I'm just always telling that to avoid disappointment later.
And different DD's have different expectations before they sponsor,
which in the end could even mean that you're doing something first and
undoing later. (But that's worst-case.)
>
> > I did only take a look a the mentors interface, especially at the
> > lintian section. It seems there are several things to be fixed:
>
> I fixed some of the issues and pushed to git, see changes at
> http://anonscm.debian.org/gitweb/?p=pkg-mysql/mariadb-10.0.git;a=log
>
> Considering that MariaDB 5.5, MySQL 5.5 and MySQL 5.6 in Debian all
> have a long list of Lintian issues, I think it is a bit too demanding
> if all Lintian issues should be addressed, but of course it would be
> nice to have as many as possible fixed.
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)
> > W outdated-autotools-helper-file -- looks like that dh-autoreconf or
> > autotools-dev would like to be your friends.
>
> Autotools is not used. These files seems to be just upstream cruft
> left over, so I added a override with this comment.
>
> > Please also the linitan errors, eg dir-or-file-in-var-run or
>
> I removed that dir. I haven't checked with upstream it it is OK, but
> obviously this one must be removed and later re-introduced as a mkdir
> line in the server startup script or similar.
Yes, as the policy says (the lintian error description has a link to the
section), you need to create it at boot-time, in the init.d script.
> > missing-dependency-on-libc
>
> Fixed.
>
> > (There are many other information errors that are easy to fix)
>
> >From my point of view all the low hanging things are done. Any help
> with nailing the remaining issues is very appreciated.
>
> > For the overriden linitian warnings: Most of those should be fixed
> > instead of overriden: binary-without-manpage
> > command-with-path-in-maintainer-script manpage-has-errors-from-man
> > If you cannot fix them now, don't override them.
>
> Are you sure? To me all these non-actionable warnings generate a lot
> of noise and hides issues I could actually address. Although when I
> look at http://lintian.debian.org/full/pkg-mysql-maint@lists.alioth.debian.org.html#mysql-5.5_5.5.35+dfsg-2
> and http://lintian.debian.org/full/pkg-mysql-maint@lists.alioth.debian.org.html#mysql-5.6_5.6.16-1~exp1
> they seem to have all these spelling errors and manpage warnings etc
> not overridden. Maybe I should indeed remove those overrides...
Argueable, there is somehow personal taste involved.
However, I think overrides are only acceptable if I cannot do something
against or if lintian is simply wrong. If the issue is valid, I do not
override but leave it open until I have a chance to fix it (it serves
also as a good reminder then.)
Also Spelling errors can be easily patched away.
(BTW, I think there also some obsolete warnings overriden; you should
remove them... Best remove all overrides, build the package, and see
what you need to re-add.)
> > Generally, if you override linitian, please do document *why* in the
> > overrides.
>
> I've now added some more comment lines into the lintian-overrides.
> Some of this packaging is inherited from years back, so as time passes
> I'll review the need for old patches and overrides and the like, but I
> do want to have some progress before I invest a lot more of my time
> into this package. Having a sponsor waiting and promising to upload if
> I work hard enough would be very encouraging..
Sure, I know that feeling. However, thats also chicken-egg-problem:
A good or perfect package is a also a advertisement for sponsors.
(However from my experience, you'll find an sponsor eventually if you
show that you care and try to deliver the best you can)
> Stopping here, as it makes no sense to review the code if there are
> > still lintian *errors*
>
> I have now found a solution to all errors now and there are only three
> "harmless" warnings left.
BTW, when you iterate, can you always upload to mentors afterwards?
The m.d.n interface is really convenient and I could then comment about
he warnings left... Using my glass-ball instead, I assume that you need
to tackle them, because there are either wrong warnings or they are not
harmless (otherwise they wouldn't be in lintian)
(I fetched the head from your git repro, but this package is huge and
takes a while to build. for example:
data.tar.xz-member-without-dpkg-pre-depends is gone )
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.
-> d/copyright needs to be updated, please use dep5 format
-> d/patches please add dep3 compliant headers (using quilt header -e
--dep3)
-> some d/patches are fuzzy, needs to be refreshed
-> 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.
-> d/changelog for new packages is just "Initial Upload (Closes:
#ITP-Bug)
-> (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.
(There is no B-D on libthrift.dev on d/control)
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)
-> There are many conflicts against mysql. Are they really needed?
It would be best if they could life in coexistance, at least
co-installable.
(Stopping here as running out of time)
Tobi
> --
> Check out our blog at http://seravo.fi/blog
> and follow @ottokekalainen
Reply to: