{"id":30,"date":"2005-05-02T00:47:22","date_gmt":"2005-05-02T00:47:22","guid":{"rendered":"http:\/\/www.reactivated.net\/weblog\/archives\/2005\/05\/ebuild-shell-blows-me-away\/"},"modified":"2005-05-02T00:48:14","modified_gmt":"2005-05-02T00:48:14","slug":"ebuild-shell-blows-me-away","status":"publish","type":"post","link":"http:\/\/www.reactivated.net\/weblog\/archives\/2005\/05\/ebuild-shell-blows-me-away\/","title":{"rendered":"ebuild shell blows me away"},"content":{"rendered":"

Since I initially raised the topic of using an ebuild to build from a custom source location<\/a> (rather than unpacking from the tarball as it normally would), a few people have questioned me — is there really a way it can be done without<\/strong> modifying the ebuild at all?<\/p>\n

Well, the answer is YES! I’ve just done it.<\/p>\n

This is largely thanks to portage-cvs’ ebuild shell<\/a> capabilities. This really is a fantastic piece of work.<\/p>\n

Here’s a quick proof-of-concept example. Note that portage-cvs<\/a> is required<\/strong> for this.<\/p>\n

For many packages, you might say that I can easily point it to use my own set of sources instead of the tarball by simply hacking a value of ${S}<\/strong> to point at my own sources, and not running the ebuild’s src_unpack<\/strong> at all.<\/p>\n

Well, what about the ebuilds that do useful things in src_unpack after unpacking the tarball? It would be nice if we didn’t have to also skip them.<\/p>\n

Again, I’m using gamin as an example. gamin-0.0.26-r6.ebuild<\/strong> has a src_unpack function which looks like this:<\/p>\n

\n
\r\nsrc_unpack() {\r\n\tunpack ${A}\r\n\tcd ${S}\r\n\r\n\t# patch to work with inotify 0.21\r\n\tepatch ${FILESDIR}\/${P}-inotify_use_fd.patch\r\n}\r\n<\/pre>\n<\/blockquote>\n
So, this is a pretty standard scenario, a tarball unpack and a small patch fix being applied afterwards.<\/p>\n
Now onto the real task. You need to install two files:<\/p>\n
    \n
  1. Install the ebuild-env<\/a> script somewhere in your PATH (e.g. \/usr\/local\/bin) and make it executable.<\/li>\n
  2. Install my ebuild.bashrc<\/a> in the home directory of your non-root user.<\/li>\n<\/ol>\n
    Next up, we’ll obtain some gamin sources. The target scenario is where you have already got gamin sources lying around in your home directory and you’ve hacked on them somewhat, but for the sake of this demonstration, we’ll put them in place ourselves. Here’s a link to gamin 0.0.26 from the Gentoo mothermirror: gamin-0.0.26.tar.gz<\/a>.<\/p>\n
    From your home-directory of your non-root user, extract the tarball as normal.<\/p>\n
    \n
    # tar xzf gamin-0.0.26.tar.gz\r\n# cd gamin-0.0.26<\/pre>\n<\/blockquote>\n
    Enter the pseudo-ebuild-environment shell:<\/p>\n
    \n
    # ebuild-env<\/pre>\n<\/blockquote>\n
    At this point, you can run commands that you normally would inside ebuilds (inherit, unpack, epatch, use_enable, etc) – but don’t do this right now, some of them require some hackery to get going and we should keep the environment clean.<\/p>\n
    Now run use-ebuild<\/strong> to prepare the environment for working with gamin-0.0.26-r6.ebuild. use-ebuild is a function included in my ebuild.bashrc<\/a> – it finds the ebuild you specify, sets up some environment variables such as ${P} and ${FILESDIR}, sources the ebuild, and sets ${S} to be the location where you called use-ebuild from (in this case, our locally unpacked gamin sources in our homedir).<\/p>\n
    \n
    # use-ebuild gamin 0.0.26-r6\r\nQA Notice: ECLASS 'eutils' illegal conditional inherit in \/gamin-0.0.26-r6\r\nQA Notice: ECLASS 'multilib' illegal conditional inherit in \/gamin-0.0.26-r6<\/pre>\n<\/blockquote>\n
    Ignore the QA notices for now. You may notice a few other odd messages appearing in this demonstration. I’m ignoring the non-critical ones for now. The important part is that the ebuild has been sourced and the environment has been modified accordingly.<\/p>\n
    So now lets unpack the ebuild, like this:<\/p>\n
    \n
    # src_unpack\r\n * Would normally unpack:\r\n * Applying gamin-0.0.26-inotify_use_fd.patch ...  [ ok ]<\/pre>\n<\/blockquote>\n
    Notice that the normal stage of unpacking the tarball from \/usr\/portage\/distfiles was skipped, it just worked on the sources it found in the current directory. Notice also that the rest of src_unpack was executed as normal – i.e. the patch was applied.<\/p>\n
    Compilation through the normal portage processes is just as easy<\/p>\n
    \n
    # src_compile<\/pre>\n<\/blockquote>\n
    Portage will now run econf and emake with all the other useful voodoo which comes with it.<\/p>\n
    And thats all there is to it. I haven’t tried src_install or merge onto live filesystem yet, but you can see I’m a good deal of the way there.<\/p>\n
    I’ve had to include some hackery in the ebuild.bashrc file to replicate the portage environment closely. At the moment, I’ve included the bare minimum to get the gamin example to work. Don’t be suprised if it fails with other packages right now, but you’ll probably find it easy to fix – it only took me 10 minutes to write the whole script.<\/p>\n
    Many thanks to ferringb<\/a> for writing the ebuild-shell functionality. I’m very impressed with how simple it was for me to chain onto portage in this fashion. I’ll add this example to the development platform<\/a> page soon.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Since I initially raised the topic of using an ebuild to build from a custom source location (rather than unpacking from the tarball as it normally would), a few people have questioned me — is there really a way it can be done without modifying the ebuild at all? Well, the answer is YES! I’ve […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-30","post","type-post","status-publish","format-standard","hentry","category-gentoo"],"_links":{"self":[{"href":"http:\/\/www.reactivated.net\/weblog\/wp-json\/wp\/v2\/posts\/30","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.reactivated.net\/weblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.reactivated.net\/weblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.reactivated.net\/weblog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.reactivated.net\/weblog\/wp-json\/wp\/v2\/comments?post=30"}],"version-history":[{"count":0,"href":"http:\/\/www.reactivated.net\/weblog\/wp-json\/wp\/v2\/posts\/30\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.reactivated.net\/weblog\/wp-json\/wp\/v2\/media?parent=30"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.reactivated.net\/weblog\/wp-json\/wp\/v2\/categories?post=30"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.reactivated.net\/weblog\/wp-json\/wp\/v2\/tags?post=30"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}