[Distutils] formencode as .egg in Debian ??

Vincenzo Di Massa hawk78_it at yahoo.it
Wed Nov 23 13:23:21 CET 2005

Alle 11:08, mercoledì 23 novembre 2005, Martin v. Löwis ha scritto:
> > easy_deb implements this, so it seems to me it would be a simple matter
> > of running easy_deb to produce the .deb from the .egg.  (Caveat: I have
> > not used easy_deb, but its author assures me that it is able to handle
> > the .pth manipulation in a sane way.)
> I can't comment on this. Somebody probably should examine whether
> easy_deb complies with all policies, and this is what the developer
> should use (I'm worried though that I don't see a mentioning
> of dpkg-buildpackage in http://www.python.org/pypi/easydeb)

easy-deb ( http://easy-deb.sf.net ) is just a tool that creates a debian 
source package. It is "more or less" like dh_make for autotools based 

What easy-deb does is:
1) downloads the python module source (using setuptools)
2) reads the python module metadata (name, version, author, dependencies...)
3) converts dependencies from pypi names to debian package names (using an 
hand written mapping database which is just a text file)
4) populates the project ./debian directory with rules, control, changelog (to 
be improved) and some post-install scripts.

Then the Debian developer is required to debuild or dpkg-buildpackage the 
sources to get the .deb as always.

The ph file is handled this way:
 it stores pth files (one per package) inside a repository (a directory 
which is not on python path). When you install a new package, a new pth file 
is added to the repository. After the pakages' pth file are added to the 
repository, the repository is used to update a single pth file inside 
site-packages (the update is done by the post-install scripts).

This way easy deb has just one pth file inside python path. 
Moreover easy-deb has cmdline tools that can disable/re-enable an egg by 
removing its pth file from the repository (the repository just contains 
symlinks to pth files like linux init scripts are just symlinks 
in /etc/rc?.d/) and re-updating the site-packages pth file.

The script for updating the site-packages pth file us named update-pypi (to 
look like update-rc.d).

The generated source debian pkg is generated from templates of rules, control, 
changelog... in which placeholders like %%VERSION%% are substituded by the 
actual metadata. If you change the templates easy-ded can create completely 
different packages without changing its code.

> > What I would suggest here is having a namespace (e.g. pyegg2.4-whatever)
> > for naming packages based on their PyPI names, so that there can be an
> > automated relationship between setuptools dependencies and Debian ones.
> That would be a policy change (I think). Whether it would be agreeable,
> I have no idea.
> > Anyway, I don't see any obvious reasons why this can't be an automated
> > process, even for the system library dependencies.  easy_deb even has a
> > simple configuration file that can augment the setuptools-style
> > dependencies with explicit Debian dependencies.
> Debian policy currently seems to require that the dependencies are
> provided as plain text in a patch to the upstream sources(*). So the
> idea certainly is that dependencies are managed by the developer,
> not automatically.

Using easy-deb dependencies are handled by the developer, but a "guessed and 
to look carefully at" list of dependencies is automatically available. 
In many circumstances the Debian developer will accept the easy-deb provided 
dependencyes making it really automatic.



Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 

More information about the Distutils-SIG mailing list