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

Re: portability as a goal for debian?



On Wed, 7 Mar 2001, Andreas Schuldei wrote:

> there is gmake, gtar and all in the ports section of the bsd,
> ready to use. it will be not very time consuming in the
> beginning. probaty more so in the long run.

> what is missing is a clean way to specify *what* we really want
> to use in the buildprocess. most package use configure anyway,
> but fail to check for make (pmake, or gmake, or whatever). In
> most debian/rules files it says #!/usr/bin/make -f
> in the first line.

Most debian/rules files don't /need/ to depend on specific versions of make.
I don't think it would hurt if packages using gmake-isms in debian/rules would
be explicit about this, but I also don't think it will be the end of Debian if
they don't.  Debian /is/ GNU-centric.  If you replace the GNU kernel with
OpenBSD's kernel, and you replace the GNU tools with the BSD tools, is it any
longer Debian?  What value is there in shoehorning dpkg onto such a system,
when OpenBSD already has a mature system for distributing additional software
(i.e., ports)?

> form debian rules configure is called. If now configure *would*
> find out that there is a pmake in /usr/bin/make and a gmake (what
> this package needs) in /usr/bin/gmake, I see no way to fix that.

> configure would need to recreate the rules file with a line
> #!/usr/bin/gmake -f form a rules.in and restart the build
> process.

> Is that possible?

You should not use autoconf to rewrite the debian/rules file.  For one thing,
debian/rules has to be understandable by the make command /before/ you can run
configure, so you'd have to bootstrap the process -- ugly kludge.  If you use
GNU-isms in debian/rules, and you want to make sure gmake is available, change
the interpreter line to point to gmake or something.  (Hmm, I see the make
package doesn't provide '/usr/bin/gmake', perhaps it should?)

And if the upstream code uses autoconf, it doesn't need to find out what make
you're using -- autoconf itself is a portability tool that eliminates the need
for gmake-isms in your makefiles.  (I have strong feelings about this -- if
you're going to use autoconf in the name of portability, don't do a half-assed
job of it.  Don't go to the effort of making sure your program will compile
under AIX if you're not going to let people do it with the AIX tools.)

> But this is just a symtom of our focus on gnu tools, without
> beeing explicit about it. (And I do not thing that we become
> explicitly gnu-focused. the opposit is true, we should try and
> use the common funktionality subset)

I've used systems that provide the common functionality subset and I think
they're painful.  Even if Debian's base system could be made to work with
these other tools, I don't want Debian to be associated with pain.  The
'Debian' name should be a mark of excellence, and its presence should tell the
world "This distribution includes the tools you need to be productive."
Anybody can provide an OS that's POSIX-compliant.  We should be able to do
more.

Steve Langasek
postmodern programmer



Reply to: