Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 135181 - Prototype for new eclass: override.eclass
Summary: Prototype for new eclass: override.eclass
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Default Assignee for New Packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-01 09:53 UTC by Dani Church
Modified: 2006-06-02 18:53 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
override.eclass (override.eclass,1.97 KB, text/plain)
2006-06-01 10:08 UTC, Dani Church
Details
sys-kernel/genkernel-selinux/genkernel-selinux-3.3.11d.ebuild (genkernel-selinux-3.3.11d.ebuild,312 bytes, text/plain)
2006-06-01 10:12 UTC, Dani Church
Details
sys-kernel/hardened-kernel/hardened-kernel-2.6.14-r8.ebuild (hardened-kernel-2.6.14-r8.ebuild,1.23 KB, text/plain)
2006-06-01 10:16 UTC, Dani Church
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dani Church 2006-06-01 09:53:11 UTC
I've created an eclass of primary use to overlay developers that I'm using in my own Gentoo-based system.  It allows a package to essentially "inherit" the properties of another existing package, much in the same way as one might inherit from a superclass in an object-oriented programming language.  The eclass is very rudimentary (hence "Prototype for"), but I think it can be useful to other people, and that if someone wants to clean it up (or there's enough interest that someone ask me to clean it up), it could go in the main Portage tree.  I am attaching the actual eclass along with a couple of example ebuilds to show its usage.
Comment 1 Dani Church 2006-06-01 10:08:46 UTC
Created attachment 88110 [details]
override.eclass

This is the override eclass.  It provides two primary functions for use by inheriting ebuilds: override() and alongside().  The only difference between the two is that override() adds the overridden package as a block to the RDEPEND variable, i.e. it does not allow the overriding package to coexist with the overridden package on the system.  The argument to override() or alongside() is the full name of a package ("category/packagename") without a version number; the override eclass will only override an ebuild with the exact same version number ($PVR) as the overriding ebuild.  All global variables (IUSE, DESCRIPTION, SRC_URI, etc.) are imported into the current ebuild.  The new variables OVERRIDE_PN, OVERRIDE_P, OVERRIDE_PF, and OVERRIDE_FILESDIR are set to the equivalent values of these variables in the target ebuild (and all references to ${PN}, ${P}, etc. in the target ebuild are modified to reflect these override variables).  The variable S is defaulted to "$WORKDIR/$P", although it will take the value set in the target ebuild if there is one.  All functions are imported, but the Portage functions (pkg_*, src_*) are imported with the names override_{pkg|src}_*.  Any of these functions that are not defined in the overriding ebuild will take the value they would have from the target ebuild.  To add to an existing function, define it and call override_{funcname} somewhere in the function.
Comment 2 Dani Church 2006-06-01 10:12:44 UTC
Created attachment 88113 [details]
sys-kernel/genkernel-selinux/genkernel-selinux-3.3.11d.ebuild

This is an example of a simple ebuild that overrides an existing ebuild.  In this case, it applies a couple patches (not included here) to the source and allows it to install normally.
Comment 3 Dani Church 2006-06-01 10:16:39 UTC
Created attachment 88115 [details]
sys-kernel/hardened-kernel/hardened-kernel-2.6.14-r8.ebuild

This is a more complicated ebuild that can be installed alongside its target ebuild (hardened-sources).  It changes the description and adds to the DEPEND and RDEPEND variables.  It also completely overrides the src_compile and src_install functions (the latter being necessary for an alongside ebuild), as well as removing the bindings for the pkg_preinst and pkg_postinst functions by overriding them with empty functions.
Comment 4 Brian Harring (RETIRED) gentoo-dev 2006-06-02 18:40:49 UTC
Interesting trick- you've replicated what eclasses are about (a template for an ebuild), 'cept you missed the staleness checks :)

Demonstration of the flaw- x overrides y.  change x, emerge -s x, change y adding something new into the depends, then run emerge -s y (do _not_ touch x, else you'll trigger a regen).

The new depends won't bleed through; this is why there is the inherit func, and INHERITED var- it tracks what eclasses were used, and triggers regeneration dependant on the timestamps involved for the ebuild _and_ the eclass.

So... have to track what was pulled in.  My suggestion?  read through glep33, specifically package level eclasses; need the env saving protection that glep33 talks about to do this, but essentially you just define an eclass/template in the packages directory instead of the tricks you're doing.

Meanwhile, this one it's an invalid...
Comment 5 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2006-06-02 18:41:33 UTC
marking invalid for ferringb.
Comment 6 Brian Harring (RETIRED) gentoo-dev 2006-06-02 18:53:01 UTC
pardon, screwed up the example slightly (yes I'm an idiot most days).
foo-2 overrides/inherits bar-1, specifically doesn't change the description though.
emerge -s foo bar;
modify bar-1, changing the description
emerge -s bar, note the description came through.
emerge -s foo; note the description did *not* come through.