Sie sind nicht angemeldet.
Lieber Besucher, herzlich willkommen bei: GentooForum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.
24.11.2008, 15:54
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »dyle« (25.11.2008, 06:04)
24.11.2008, 16:07
|
Quellcode |
1 2 3 4 5 6 |
src_unpack() {
unpack ${A}
cd "${S}"
epatch "${FILESDIR}"/${P}-gentoo.patch
AT_M4DIR=m4 eautoreconf
}
|
|
|
Quellcode |
1 |
epatch "${FILESDIR}"/EURE-PATCH-DATEI
|
|
|
Quellcode |
1 2 3 4 5 6 7 |
src_unpack() {
unpack ${A}
cd "${S}"
epatch "${FILESDIR}"/${P}-gentoo.patch
epatch "${FILESDIR}"/ftgl-2.1.3_rc5_Makefile.patch
AT_M4DIR=m4 eautoreconf
}
|
|
|
Quellcode |
1 |
# ebuild /usr/portage/media-libs/ftgl/ftgl-2.1.3_rc5.ebuild manifest |
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »dyle« (24.11.2008, 16:18)
24.11.2008, 16:16
|
|
Quellcode |
1 |
# export EB="/usr/portage/media-libs/ftgl/ftgl-2.1.3_rc5.ebuild" |
|
|
Quellcode |
1 |
# ebuild ${EB} unpack
|
|
|
Quellcode |
1 |
# patch -p0 < PATH/To/PATCH |
|
|
Quellcode |
1 2 3 4 5 |
# export EB="/usr/portage/media-libs/ftgl/ftgl-2.1.3_rc5.ebuild"
# ebuild ${EB} unpack
# cd /var/tmp/portage/media-libs/ftgl-2.1.3_rc5/work/ftgl-2.1.3~rc5
# patch -p0 < ~/ftgl-2.1.3_rc5_Makefile.patch
# ebuild ${EB} merge
|
29.12.2010, 22:55
Zitat
Easy Patching Hint:
FWIW, I don't know exactly when this VERY USEFUL new portage feature was
introduced, but all latest current versions (2.2/sets, 2.1.9.26 ~arch and
2.1.9.25 stable, at least) of portage appear to have this feature now....
Instead of worrying about updating the ebuild when you have "user" patches to
apply like this one, in /most/ cases, you can simply drop the patch as a file
in /etc/portage/patches/cat-egory/package(-version-optional)/*.patch and
portage will automatically try to apply it for you. =:^)
So for this one, I dropped the patch in:
/etc/portage/patches/kde-base/pykde4-4.5.4/pykde4-typedefs-fix.patch
Point: Make sure permissions on the directory chain are readable by the portage
user (and for security reasons, probably owned and only writable by root, you
don't want arbitrary users being able to apply whatever patches they want).
Point: The package dir version number is optional. In this case, I decided the
patch isn't likely to be needed (from my side) for more than a single version,
so I used the version number in the patches dir, so it won't apply to the next
one automatically. If it's your own patch to package functionality, you might
want to omit the version, so it automatically applies whenever the package
upgrades. I did that with one (kde3) package for awhile.
Point: The name of the patch file itself was the same one it has in bugzilla.
I saw no reason to change it, but I did change ownership (from the user I had
downloaded it as) and permissions as appropriate.
Here's what that the prepare phase of the the package build look like when it
finds a user patch in /etc/portage/patches/* to apply (using this package and
patch as an example):
>>> Preparing source in /tmp/portage/kde-base/pykde4-4.5.4/work/pykde4-4.5.4 ...
* Applying pykde4-mapped-type-fix.patch ...
[ ok ]
* Applying user patches from /etc/portage/patches//kde-base/pykde4-4.5.4 ...
* pykde4-typedefs-fix.patch ...
[ ok ]
* Done with patching
>>> Source prepared.
Note the "applying user patches"... bit and that it's NOT just the usual ebuild
listed patches applied! That's the new feature. =:^)
Just drop that patch in the appropriate /etc/portage/patches/ subdir, change
the ownership and permissions appropriately from what you happen to download
the patch-file as, and re-emerge the package. As you can see, once it's in the
proper location, portage automatically detects it and applies it for you. =:^)
In MOST cases, that eliminates any need to copy the ebuild to an overlay, add
the line applying the patch, and then re-digest the ebuild, since portage
handles it all automatically now, without even changing the ebuild. All you
have to do is have the patch in the right place and readable. =:^)
Occasionally you might come across a complex case where the automatic method
doesn't work and you have to do the ebuild-edit-and-redigest thing, but that
doesn't happen very often. (I've been using an earlier version of this for
years now, even using it when I was applying patches to help packages build
with a still-masked gcc version, as I usually unmask those well ahead of when
they hit ~arch, and have only had the automatic handling fail on me a couple of
times.)
As I said, even latest stable portage (well, I didn't test the old versions for
the lagging archs, but 2.1.9.25 has it, anyway) has this feature now. My
overlay gets WAY less use that it did before this feature, for sure, and where
the only reason you're using the overlay is to apply a patch like the one
attached to this bug, yours probably won't get as much use now either. =:^)
Duncan
