automake
[Top][All Lists]
Advanced

[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: Thu, 05 Oct 2006 01:58:12 -0700
User-agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)

Ryan McDougall <address@hidden> writes:

> should I understand that (for example) when redhat/debian build lets say
> libc for packaging as a binary, they download a tarball and do a
> complicated form 
> './configure --prefix=/usr && make && make install' on a bare machine
> without any libc, then tar up the result for an RPM or DEB?

In general, with Automake-using packages, Debian packaging uses DESTDIR to
configure the package with a prefix of /usr and then install it into a
temporary directory which can then essentially be tarred up.  However, the
complete practice is more complex than that.  Most of what goes into
creating good packages is dependency management and consistency across the
entire packaging system.

For a detailed look at Debian packaging, see:

    <http://www.debian.org/doc/manuals/maint-guide/>
    <http://www.debian.org/doc/debian-policy/>
    <http://www.debian.org/doc/manuals/developers-reference/index.en.html>

The first is the Debian New Maintainers' Guide and the best introduction.
The second is the authoritative reference on how a Debian package should
behave.  The third is a collection of advice which includes packaging best
practices as well as other things.

Note that proper packaging of shared libraries is an extremely complex
affair, something on which we actually test new Debian developers due to
the variety of issues that have to be learned and handled correctly.  See:

    <http://dancer.debian.net/~dancer/column/libpkg-guide/libpkg-guide.html>

for many of the issues.  Most of those issues come about not from the
problems of a single isolated package but from the complexities of keeping
an entire distribution of tens of thousands of packages internally
consistent, maintainable, and rebuildable on an automated basis.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>




reply via email to

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