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 <[email protected]>: > > 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/[email protected]#mysql-5.5_5.5.35+dfsg-2 > and > http://lintian.debian.org/full/[email protected]#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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
