[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 
davidw@prosa.it            )    multa sunt suspiria
http://www.efn.org/~davidw (    de tua pulchritudine
debian.org + prosa.it      )    que me ledunt misere

Reply to: