Re: [gentoo-dev] g-elisp repository helper
21.02.13 16:18, Ulrich Mueller написав(ла): > It looks promising. I only wonder why you need to define your own > fetch function instead of assigning SRC_URI? This will cause the > ebuilds to be live ebuilds and there will be no possibility for the > user to verify the integrity of the downloaded package. Or have I > missed something? > > > Cheers, > Ulrich > Thanks. The problem with SRC_URI is that if it is defined, manifests should include hashes of the source files. As g-elisp is aimed to dynamically generate overlays on user's computer it means that during this generation all the sources from elisp repos will be downloaded. It isn't very nice. The integrity of sources could be verified in ebuild, but I have not found any hashes in elpa's repository info. May be I just failed in my googling, so if you know a solution of this problem, I will implement it with great pleasure. Best regards, Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] g-elisp repository helper
> On Thu, 21 Feb 2013, Ulrich Mueller wrote: > No problem with posting it to the gentoo-dev list. I'm answering in > semi-private (Gentoo Emacs team in CC) because the topic is Emacs > specific. I fail.
Re: [gentoo-dev] g-elisp repository helper
> On Wed, 20 Feb 2013, Jauhien Piatlicki wrote: > I do not know whether this list is an appropriate place, so sorry if it > is not ) Hi, No problem with posting it to the gentoo-dev list. I'm answering in semi-private (Gentoo Emacs team in CC) because the topic is Emacs specific. > Recently I've wrote some little scripts that implement interface for > g-common type repositories of layman[1]. And I would ask those who is > interested to test them. > I've created two packages: g-common (interacts with layman) and g-elisp > (generates ebuilds). g-elisp is aimed to automatically create layman > overlays for repositories of elisp packages supported by package.el, so > those packages could be installed by portage. > To test it you can add an overlay described by this xml-file: > https://github.com/jauhien/jauhien-overlay/blob/master/jauhien-overlay.xml > and then `emerge g-elisp` > After emerging it you will be able to add two layman repositories of > type g-common: gnu-elpa and marmalade. It looks promising. I only wonder why you need to define your own fetch function instead of assigning SRC_URI? This will cause the ebuilds to be live ebuilds and there will be no possibility for the user to verify the integrity of the downloaded package. Or have I missed something? > g-common and g-elisp are still in the very beta, also I'm a very > beginner in python, so I will appreciate any feedback and criticism. I fear that I won't be able to help you with the Python. Cheers, Ulrich
[gentoo-dev] g-elisp repository helper
Hi all, I do not know whether this list is an appropriate place, so sorry if it is not ) Recently I've wrote some little scripts that implement interface for g-common type repositories of layman[1]. And I would ask those who is interested to test them. I've created two packages: g-common (interacts with layman) and g-elisp (generates ebuilds). g-elisp is aimed to automatically create layman overlays for repositories of elisp packages supported by package.el, so those packages could be installed by portage. To test it you can add an overlay described by this xml-file: https://github.com/jauhien/jauhien-overlay/blob/master/jauhien-overlay.xml and then `emerge g-elisp` After emerging it you will be able to add two layman repositories of type g-common: gnu-elpa and marmalade. g-common and g-elisp are still in the very beta, also I'm a very beginner in python, so I will appreciate any feedback and criticism. Jauhien [1] http://git.overlays.gentoo.org/gitweb/?p=proj/layman.git;a=blob;f=layman/overlays/g_common.py;h=5f0e9bc341028248ccd718eff84d304100180949;hb=HEAD https://github.com/jauhien/g-common https://github.com/jauhien/g-elisp signature.asc Description: OpenPGP digital signature
