diff options
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 60 |
1 files changed, 4 insertions, 56 deletions
@@ -1,60 +1,10 @@ -Objective -========= - -There is a lot of 3rd party software providers that resemble overlays -or repositories of Linux distributions in some way. For example: pypi, -CRAN, CPAN, CTAN, octave-forge, ELPA. It's clear that all this -software available through different mechanisms (such as package.el -for Emacs or pkg command in Octave) will never have separately -maintained ebuilds in Gentoo tree or even in overlays. Installing such -a software with its own distribution system does not seem like a good -idea, especially if one needs to install it system-wide. - -There is a number of solutions for this problem in Gentoo. But here -another problem lies: there are special dedicated “g-helpers” for a -number of 3rd party software providers. But, as Rafael Martins states -“each one tries to solve the very same problems on its own unique and -"innovative" way”. While it would be really nice to have a solid base -framework with realization of all the basic algorithms necessary for -ebuild and overlay generation, with uniform UI and with good -integration with system package manager. - -Deliverables - -At the end of the project there should be a framework and number of -backends for some of the 3rd party software providers. This framework -should make writing of those g-helpers easier and regular. - -At the moment I see this framework as a number of classes in Python -that can be inherited and expanded in backends with the specific -logic. All the logic related to the interaction with user, portage and -overlay tools should be implemented in the framework and normally -should not be changed by backends. Integration with system may need -patching of some existing tools (like layman). - -Framework should have: - basic logic for ebuild and overlay -manipulation, dependencies resolving, patching and so on - cli, that -allows users to generate separate ebuilds and even overlays with -available backends - integration with other system tools (I mean -layman, as I'm not really familiar with tools used by other package -manglers. But supporting them would be a good idea as well). - -Backend should have everything specific for a given 3rd party software -provider: concrete algorithms for ebuild-generation, eclasses, -databases with information about available software and so on. +This is [g-sorcery](https://github.com/jauhien/g-sorcery) backend for elisp packages. + Installation and using ====================== -You should emerge **app-portage/layman-9999**. - -Add `jauhien` overlay: **layman -a jauhien**. - -Emerge g-sorcery: **emerge -va g-sorcery**. - -Currently 3 backends are available: **gs-elpa**, **gs-pypi** and **gs-ctan**. - -Here is an example of using gs-elpa backend. +Installation: in progress (use dev-portage/g-sorcery-9999, at the moment it has bundled backends). There are two ways of using **gs-elpa**: @@ -127,6 +77,4 @@ Repositories you can use are gnu-elpa, marmalade and melpa. You can use them all in one overlay. Note, that if you call **generate-tree** command your overlay will be wiped and overlay tree for a given repository will be generated. Be careful! -See man pages of **gs-elpa**, **gs-pypi** and **gs-ctan** for further information. - -If you want to develop a new backend see [developer's instructions](https://github.com/jauhien/g-sorcery/blob/master/docs/developer_instructions.rst). +See man page of **gs-elpa** for further information. |