[Top][All Lists]

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

Re: autotools not suited to proprietary development?

From: Russ Allbery
Subject: Re: autotools not suited to proprietary development?
Date: Fri, 06 Oct 2006 16:17:30 -0700
User-agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)

Warren Young <address@hidden> writes:

> It's not that autotools do the wrong thing, it's that we're currently
> missing a tool that you might call "autopackage".  It would need to make
> RPMs and DEBs on Linux, EXEs on Windows, PKG+MPKG+DMG bundles on OS X,
> etc.

There are a *lot* of decisions that go into making a high-quality Debian
package.  I suppose that it would be possible to do something automated
that would at least be an improvement over a tarball installation, but I'm
skeptical of automatically generating Debian packages in general.  A
Debian package is not just a mechanical accumulation of files; it
incorporates a large amount of metadata about the package and its
dependencies and installation process that's not easily derivable without
detailed knowledge of how the package is supposed to work.

> An autopackage tool would be nice to have, but it'd need to be awfully
> smart to be useful.  Package deployment differs greatly among
> platforms. You've got the deep FHS tree on Linux, /Applications and .app
> bundles on OS X, c:\Program Files on Windows...and that's just the
> start, because you probably have to distribute a different set of files
> on each platform: there are a lot of places where there is no 1:1
> correspondence between a file you must have on one platform and what is
> needed to get the same result on another platform.

Yeah, and that's just the tip of the iceberg; the metadata required is
different on different platforms, Red Hat packages have to deal with the
many different flavors of Red Hat that you could be targetting, Debian
packages should be broken up properly when they contain shared libraries
and library development files, init script handling is completely
different between systems, etc.  And that's not even getting into
install-time configuration options, debconf prompting, translations, and
similar complexities.

Russ Allbery (address@hidden)             <>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]