Re: Increasing regularity of build systems
On Wed, Sep 15, 1999 at 01:30:20PM +0300, Antti-Juhani Kaijanaho wrote:
> > > > Joey Hess' debhelper scripts are a good API, maybe it would be
> > > > good to standardize on them to some degree.
> > > No.
> > I didn't say "make them THE standard"
> What did you mean then?
I think that as many packages as reasonably possible should migrate
towards them. They work pretty well, but I don't believe in forcing
them on people if they are really opposed.
> > Currently, anarchy reigns within debian/rules,
> > and it's a pain to work with.
> Can you be more specific?
Lots of packages work quite differently. Postgresql, for example, has
a nice rules file that works like a makefile should - it starts up
where it left off. Recently, I've encountered a few that don't do
this (not to pick on anyone, though).
Gpm - runs configure every time.
Xemacs21 - runs *autoconf* to generate other makefiles, which are then
Apache - unpacks a bunch of tarballs of upstream stuff and patches,
and proceeds to work on those. Basically, orig.tar.gz doesn't contain
the pristine upstream sources, but a tarball of them.
Do you seem what I mean? Each of these is doing something slightly
different, and it is a bit frustrating not to see a bit more
cohesiveness. Not that any of these things are *bad*, per se, just
that there seem to be a lot of packages that do stuff like this.
> > Do you have any constructive criticism,
> My constructive criticism is that you have not given any good reason for
> making everybody use debhelper. If you had, I might have considered
> reiterating the well-known old arguments against this idea. And you
> can still do it.
I'm not just talking about debhelper, but about rules files in
general. I think using debhelper is one part of this.
> > or a better alternative?
> Yes. Don't standardise on debhelper. Rather fix the specific
> problems you might have by amending policy to require certain things
> without locking everybody down to a particular helper package.
> Right now your concerns are vague and I'm not at all sure your
> proposed solution is a good solution.
> Besides, this all belongs in -policy, not -devel.
Policy is not the be all and end all of Debian - frankly, it doesn't
interest me much. I am interested in finding a good technical
solution to our problem, and those of you that are interested in
policy can decide what you want to do about it.
You are right, I've been a bit vague, but that's because it's not one
specific bug. It's a general problem that manifests itself in
different ways that are difficult to discuss on a general level. And
yet, it's good to at least talk about it at this level so as to try
and come up with a set of good guidelines to go by before going out
and doing a package by package combing of Debian.
David N. Welton ( Circa mea pectora
email@example.com ) multa sunt suspiria
http://www.efn.org/~davidw ( de tua pulchritudine
debian.org + prosa.it ) que me ledunt misere