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 projects. 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. Vincenzo ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.messenger.yahoo.com
