Talk:HOWTO Create an Updated Ebuild
From Gentoo Linux Wiki
After an Ebuild has been updated and tested it should be sent to the Devs for inclusion to portage. I think this is supposed to be done via Bugzilla but I'm not sure.
File a bug if one hasn't already been filed and add an attachment containing your updated ebuild. Explain why your ebuild should be added to portage and a dev should reply Masterdriverz:Talk 11:35, 13 April 2006 (UTC)
Contents |
[edit] Script to make an overlay ebuild?
Suppose i want to modify or bump an ebuild. Is there any script so that:
eoverlay my-cat/my-ebuild-0.1.2
will copy my-ebuild to my overlay. Then:
ebump my-cat/my-ebuild-0.1.3
will make new ebuild my-ebuild-0.1.3 based on the lastest ebuild in overlay.
- Yes, bumper. See TIP_Portage_utilities_not_in_portage#Emerge_Utilities ecatmur 20:29, 12 February 2006 (GMT)
[edit] Feature missing ? or lame user (me)
(mylife) I try to install mailman, that needs to have MAILGID=2 instead MAILGID=280 in mailman-...ebuild the only "clean" way to make it I found was... this article.
Is there a REALLY clean way of doing that (a way that will follow updates on portage for instance :) ? (if no, then I think the article should talk about it, doesn't it ?)
- If you file a bug on bugs.gentoo.org demonstrating a real need to set MAILGID (i.e. it can't be done any other way) then the devs may provide a way to e.g. pass in MAILGID from env. In the meantime, setting EXTRA_ECONF=--with-mail-gid=2 could work. ecatmur 20:34, 12 February 2006 (GMT)
[edit] examples
patch:
diff -urN a/Makefile.inc b/Makefile.inc
--- a/madwifi-ng-r1443-20060207/Makefile.inc
+++ b/madwifi-ng-r1443-20060207/Makefile.inc
@@ -173,12 +173,12 @@
# Path to the HAL source code.
#
ifeq ($(HAL),)
-HAL= ${obj}/${DEPTH}/hal
+HAL= ${DEPTH}/openhal
endif
#
# Path to the HAL build area.
#
-ATH_HAL=${DEPTH}/ath_hal
+ATH_HAL=${DEPTH}/openhal
#
# Path to the 802.11 include files.
#
ebuild:
cd ${S}
epatch "${FILESDIR}"/OpenHAL-linux.patch
ebuild with use flag:
IUSE="amrr onoe OpenHAL-linux"
if use OpenHAL-linux; then
einfo "OpenHAL used"
einfo "${S}"
cd ${S}
epatch "${FILESDIR}"/OpenHAL-linux.patch
fi
file with multiple patch:
diff -urN a/CREDITS b/CREDITS --- a/CREDITS +++ b/CREDITS @@ -52,6 +52,12 @@ S: Buenos Aires S: Argentina +A: Dan Aloni +E: da-x@colinux.org +D: Cooperative Linux +D: Various kernel patches +S: Israel + N: Tim Alpaerts E: tim_alpaerts@toyota-motor-europe.com D: 802.2 class II logical link control layer, diff -urN a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -318,6 +318,11 @@ AS = $(CROSS_COMPILE)as LD = $(CROSS_COMPILE)ld CC = $(CROSS_COMPILE)gcc +ifeq ($(GCCTRACE),Y) +CC = $(COLINUX_ROOT)/bin/tracewrapper.py $(CROSS_COMPILE)gcc +else +CC = $(CROSS_COMPILE)gcc +endif CPP = $(CC) -E AR = $(CROSS_COMPILE)ar NM = $(CROSS_COMPILE)nm
[edit] Patching kernel modules
When a kernel module needs to be patched (for example net-wireless/rt2x00), will adding a src_unpack() still work? Or is the procedure a little different for this scenario?
[edit] Updating Manifest
I'm not sure if I'm right here because I'm a total noob in regards to portage, but shouldn't the path for updating the manifests be /usr/local/portage/... ?
- It probably should. I've updated it.
- --AllenJB 17:09, 12 January 2008 (UTC)
[edit] unmasking the ebuild
I just created a ebuild containing a custom patch following this howto. But I didn't have to unmask the ebuild, as it seems like portage respects the KEYWORDS variable also in overlays. I don't know wether this was different in earlier portage versions, but with portage-2.1.4.4 this step is unnecessary.--Liwo 13:05, 27 May 2008 (UTC)
- It's always been this way for as long as I can remember. It's basically common practice that overlay packages should be marked testing so that when users add an overlay, they only get exactly the packages they want from the overlay and the rest are obtained from the main tree to avoid unexpected issues.
- --AllenJB 13:36, 27 May 2008 (UTC)
