Hello, I have written and just pushed to GitHub two ebuild files for Pygr:
http://github.com/mkszuba/pygr/commit/98a69047ef3c2aa53b06c85183a4bdadff1cd3f4 In case the name 'ebuild' doesn't mean anything to you, let me briefly explain. Unlike most Linux distributions, which use binary packages, Gentoo Linux follows the concept of PORTS originally introduced by (IIRC) FreeBSD: instead of binaries, provide instructions for automatically building packages from source. In case of Gentoo Linux, the system for managing ports is called Portage (and has been written in Python), whereas instruction files are called ebuilds. There are two ebuild files available: pygr-VER.ebuild, which pulls official packages from Google Code (VER should be replaced with version name in the repository), and pygr-9999.ebuild, which pulls Pygr sources from Git (using 9999 in case of such ebuilds is a convention of Portage). Thanks to distutils, both are mostly declarative - only running tests and building/installing documentation, i.e. tasks which do not directly correspond to setup.py directives, required defining. SQLite and MySQL are specified as run-time dependencies, if needed; Sphinx is a build-time dependency if off-line documentation is to be installed; Pyrex is a build-time dependency only if pulling sources from Git. The two files have been added to the top-level directory, as I am not sure at this point whether we should actually have them merged into the master. Ebuilds do not really belong to packages they describe, the ultimate goal of creating such a file is to have it included in a Portage repository (preferably the primary, Gentoo-maintained one - which unfortunately depends on whether any maintainers are interested in maintaining it. Then again, Biopython is in there so we've got a chance.). Not to mention that one needs to get the ebuild first and the package afterwards. From this point of view, it may make more sense to have them posted on Google Code. On the other hand, keeping them in Git may help us keep them up to date... Last but not least, if we do keep them in Git there is the question of the name of the directory to hold them - in case of C packages this kind of stuff (Debian package rules, RPM .spec files, ebuilds etc.) go into the 'dist' directory, which however in case of Python conflicts with distutils. 'linux' on the other hand may be too specific, as Portage also works under FreeBSD. 'misc'? Let me know what you think. -- MS --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to pygr-dev@googlegroups.com To unsubscribe from this group, send email to pygr-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
