Re: bacula_1.38.8-0.1_i386.changes is NEW
On Wed, May 10, 2006 at 01:36:47PM +0200, José Luis Tallón wrote:
> Ok. I don't like flamewars either. There are plenty on Debian-Devel.
I should point out that you CC'd your reply to this message I sent you
in private to debian-devel.
> > Unfortunate, but the proper thing to do in this situation is to announce
> > the situation and solicit NMUs from people. As far as I have seen, you
> > did not do this.
> >
> Hmm... I will keep that in mind for the next time, should it ever happen
> (hopefully not)
> But I can't see it anywhere in the Policy nor in the Developers' Reference.
http://www.debian.org/doc/developers-reference/ch-developer-duties.en.html#s-inform-vacation
> > There are several reasons I have made the NMUs I have, and that I intend
> > to take over this package. Some of them are:
> >
> > * Release-critical bugs that were open for over a year (303862)
> > or a very long time (343762). Some of these were trivial (10-second)
> > fixes.
> >
> Well... no upload = no bugfixes
I find it extremely hard to believe that you couldn't find anyone to
sponsor an upload with RC bugfixes in a YEAR, especially since you
stated that your AM had offered to sponsor uploads for you. The only
reason I could see that happening is if your packages are in such bad
shape that they don't build or that a sponsor refuses to upload it on
quality grounds. Both of which could be the case here.
> > * Bacula was removed from testing three months ago due to its
> > bugginess.
> >
> So what? that's obvious. Buggy package ==> removed from testing.
> That is how we ensure our OS's quality.
Bacula itself is not buggy. The Debian packages of it are.
[ snip a lot of stuff about databases ]
You say that you have let the PostgreSQL code languish because you don't
know PostgreSQL. Maybe. But you should know enough to know that
stopping and restarting a database server without asking permission is
terrible, and where to find the call to the init script that does that.
You could also install PostgreSQL, read its docs, and test. It isn't
all that difficult. Certainly doesn't warrant that bug being there for
years.
There are all sorts of other problems: build-dep'ing on libsqlite3-dev
when you are going to look for Sqlite v2, etc.
> > * Your clean target was ineffective and caused a huge diff.gz
> >
> For 1.38 ? Yes. Can't clean before you have it built, right?
Yes, you can, and should be able to. The debian/rules clean target
should clean the package from any state. It also didn't do a very good
job of cleaning it from being built.
> > * Bacula would link against Python 2.2 in some cases even though you
> > dep'd on python2.3
> >
> Didn't get to it, either. Fortunately, your patches address that
> problem, right?
Correct.
> > * Policy violations in numerous places, including treatment of logfiles
> >
> Touché as for the logfiles.
> I would like to know what are the other Policy violations you refer to,
> so that i can learn from those.
Here are the ones I've *noticed* (some of these are best practices as
opposed to policy violations):
* Logfiles in wrong directory
* Postrm deleting files belonging to other packages, and breaking those
packages in the process
* Incorrect build-deps on Python and Sqlite
* Missing build-deps for parts of gnome as well as mtx
* No rotation for logfiles
* Ineffective clean target
* Probably dozens of cruft files in debian/
* Hacking upstream configure system and hard-coding libraries
(which may be incorrect on different archs and Debian versions)
instead of using the suggested vim-like approach (see developer's
ref)
* Postinsts attempting to chmod files in other packages that are not
even depended upon, then failing if those files don't exist
* Bashisms in debian/rules, leading to FTBFS if /bin/bash is not
/bin/sh on a given system.
* Bashisms in maintainer scripts, leading to failure to install
if /bin/bash is not /bin/sh on user's system
* Dozens of other lintian errors and warnings -- run it yourself to
see.
> > * No rotation of logs
> >
> That's a wishlist bug. I think that 'wishlist' comes after 'grave' or
> 'important'. Do you think otherwise?
In my book, this is grave, since it can -- and has -- lead to filling up
a disk and thus rendering many other packages useless.
> > * Indiscriminate removing of /var/lib/bacula on removal, which would
> > completely break the remaining bacula packages on a system
> >
> Hmm.. never had that problem, but i understand your point.
> Please note that i also use Bacula in production in several machines.
Until you have tried to remove it, you may not have seen it.
> > * Bashisms in debian/rules.
> >
> Ok. Didn't notice those, nor did lintian or linda.
> Care to point them so that i can learn?
Please just set /bin/sh to something other than bash or zsh and try it
again.
> > * Poor handling of multiple-variants problem. Hacking up configure
> > scripts instead of just calling configure several times (see
> > the reference to vim in the debian developers' guide)
> >
> Well.... I did build Bacula that way almost two years ago, with version
> 1.32f-4 till 1.32f-6.
>
> I was publicly "reprehended" by Turbo Fredriksson due to the amount of
> CPU wasted. He cared to contribute some patches which, after being
> integrated and enhanced --as much as i could-- by me, form the current
> build system.
> His contribution meant a nearly 200% speed increase in the build
> process... still disagree with that?
Absolutely! It is completely wrong to cut build time in half at the
cost of having correct builds. The fact that you are hardcoding the
libraries to use, setting the DEBUG environment variable to forcibly
inject them into the build system, and hacking up not just configure but
m4 macros as well just makes it all that much worse.
I cannot prove to myself that your build system works with any given
version, much less know that it works after a new upstream release.
This is a BACKUP PACKAGE. It is absolutely CRITICAL that this package
work, be correct, be simple, and be usable. People depend upon backup
packages in an emergency. If it is non-obvious how to build a backup
package in an emergency, or worse yet, non-obvious that you're even
building backup or restore software correctly to start with, then your
build system is a failure.
I have already rewritten your build system to go to the suggested method
of building.
> > * Lots of unused cruft in Debian source packages.
> >
> Well... apart from some remainings from an imperfect clean target, the
> remaining contents of a Debian source package is up to that particular
> package's maintainer, right?
No. Having dozens of unused files in debian/, including a whole bunch
in debian/patches, not only wastes space but makes it more difficult for
others to work with your packages.
> > * Various binaries being installed to wrong package or to multiple
> > packages.
> >
> I have already said "alpha", have I?
It is not your place to upload known-broken software to sid. It is also
not your place to fail to test them before uploading.
> I didn't even have the opportunity to build the packages myself until
> this weekend.
> > As it was, the Bacula packages as they existed in sid were neither
> > buildable nor installable.
> Yes, due to the static linking.
No, statically-linking something doesn't render it unbuildable or
uninstallable. Did you even look at the BTS?
You've got:
#303862, in which a postinst script tries to chmod a file that doesn't
exist
#343762 and #358762, in which you build-dep on a mysql package that
doesn't exist
#337250 in which your build scripts refer to a file that doesn't exist
I would also argue that #309601 (postgresql install failing due to
trying to modify a file that doesn't exist), #329271 (insecure temp
file creation), #331757 (incorrect debconf deps), #339341 (depending on
old postgresql clients), and #309675 (failure to rotate logs) should
have been RC as well. Many of these cause a failure to install or
build. In addition to these, the unreported bugs that I found (all the
incorrect build-deps plus the other things I mentioned above) could lead
to a failure to build or install.
> > I actually already have it in darcs, and all the changes I have made
> > so far are in darcs. I could publish that if you'd like.
> >
> Yes, please.
> I don't consider myself the best maintainer ever, and so am willing to
> learn.
darcs get --partial http://darcs.complete.org/debian/bacula
> The final decision was to keep the package with an RC bug to avoid it
> migrating to testing.
> I adopted the package because i felt that providing support for Reiserfs
> in Parted would be good for our users. Unfortunately, libreiserfs is
> neither supported nor maintained upstream, and will have to go away soon
> (i.e. be removed)
Then you should file a bug on ftp.debian.org and, at minimum, note that
you have requested it removal here.
[ much snippage ]
> > I intend to follow through on that, and am already well on my way to
> > rewriting the build system and fixing many additional bugs. I should
> > add that I mis-placed the comment about you not being a DD; it is not a
> > reason in itself for taking over the package and should be been listed
> > separately.
> >
> Well.. if you don't trust me (you need not) ask Turbo and PMHahn about
> the build system.
I need not ask them. I have already seen for myself that it is broken.
The fact that Turbo wrote something a long while ago doesn't mean that
1) it still works today, 2) that you didn't mess it up, or even 3) that
it was correct to begin with. I know Turbo does good work, so I think
that #3 is unlikely, though.
> > I do appreciate the effort you have put into Bacula over the years and
> > am pleased that you are interested in participating with its development
> > once again.
> again? I'll pretend you didn't say that.
I didn't mean it as an insult, but again, looking at the BTS and PTS,
there's been really no improvement from you since July 2005.
> > Once I get Bacula's build system rewritten, to a more sane
> > state, I would be glad to work on Bacula with you (or others) and would
> > be happy to accept patches, with Darcs or otherwise.
> >
> Bacula's build system's "sanity" seems to be controversial.
> My first packaging used the system you propose to use now... the new one
> is around 200-300% faster (one build + three partial builds vs four
> complete builds)
You needn't ever have done four complete builds. By varying slightly
the arguments to configure, as I have done in my darcs repo, I build the
GUI consoles only once.
My rewrite is not finished yet, and the packages are not completely
correct yet, so please do not take what is in darcs now to be usable or
the final state of things. But most of the hard part is done.
> > I have no hard feelings towards you, and hope that you won't be angered
> > by this.
> Well... you message this morning was really offensive to me.
> > It's nothing personal -- just an effort to improve the Bacula situation in Debian.
> >
> Then, continue doing NMUs (if it's not personal) and help me where you
> see fit.
That is not sufficient:
* The NMU mechanism is not intended to be used for major changes to
the build system of a package. Bacula desperately needs that.
* I have no reason to believe that you would actually apply and upload
patches in a timely fashion. You seem to believe, for instance,
that your hackish build system is more correct.
* I can not, at this moment, trust you to refrain from doing something
that would break Bacula again in the future.
* I would not be comfortable with having your code in Bacula until
I've been able to review it.
* You have been inactive, as far as Bacula in Debian is concerned, for
almost a year. I find it likely that I would be de facto maintainer
anyway.
* Your ability to actually build Debian packages at all, and test them,
seems to be in doubt.
-- John
Reply to: