Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds
Does anyone think that a mechanism of applying patches to a package without the need to modify the ebuild of that package would be a useful feature? media-video/smplayer j-random-hack.patch i have written script (not at my hand atm) with alike syntax using post_src_unpack pre_src_compile hooks. script needs to push patch inside proper directory /etc/portage/... and remove it after emerge. no editing of files around like the /etc/portage/bashrc trick. i can dig the script out if you are interested. pavel
[gentoo-user] Applying patches without needing overlays and modifying ebuilds
Does anyone think that a mechanism of applying patches to a package without the need to modify the ebuild of that package would be a useful feature? There are cases of useful patches that are not accepted by the maintainers of the ebuild (because they have not been accepted upstream or other reasons), forcing users to copy ebuilds in their overlay and modifying the ebuild there. This turns out to be a hassle every time the package receives an update. What if we could just specify patches to be applied in, say, /etc/portage/packages.patch with something like: media-video/smplayer j-random-hack.patch and portage would apply that patch automatically? That way, the hassle of updating the ebuild of a package in which I use custom patches would go away. The patches could be searched for in a designated directory, in this example maybe /var/portage/patches/media-video/smplayer (or something else entirely.) Can someone think of a way to set up something like this?
Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds
Nikos Chantziaras wrote: Does anyone think that a mechanism of applying patches to a package without the need to modify the ebuild of that package would be a useful feature? There are cases of useful patches that are not accepted by the maintainers of the ebuild (because they have not been accepted upstream or other reasons), forcing users to copy ebuilds in their overlay and modifying the ebuild there. This turns out to be a hassle every time the package receives an update. What if we could just specify patches to be applied in, say, /etc/portage/packages.patch with something like: media-video/smplayer j-random-hack.patch and portage would apply that patch automatically? That way, the hassle of updating the ebuild of a package in which I use custom patches would go away. The patches could be searched for in a designated directory, in this example maybe /var/portage/patches/media-video/smplayer (or something else entirely.) Can someone think of a way to set up something like this? Patches are already stored in a files directory. For instance, it would be /var/portage/media-video/smplayer/files in your example. Maybe I'm missing some point you were trying to make.
Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds
Nikos Chantziaras rea...@arcor.de writes: What if we could just specify patches to be applied in, say, /etc/portage/packages.patch with something like: media-video/smplayer j-random-hack.patch and portage would apply that patch automatically? That way, the hassle of updating the ebuild of a package in which I use custom patches would go away. One problem here is the order of patches. Often the order that the patches need to be applied is important, and your mechanism does not allow you to specify the order with respect to those patches in the ebuild. Another problem is that when a package is upgraded, the patches required can change. The patch that worked with version X might have to be changed for version X+1 or may not be needed any more. So it is necessary to do some work anyway when upgrading packages.
Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds
On Sun, 17 May 2009 09:44:19 +0300, Nikos Chantziaras wrote:
Does anyone think that a mechanism of applying patches to a package
without the need to modify the ebuild of that package would be a useful
feature? There are cases of useful patches that are not accepted by
the maintainers of the ebuild (because they have not been accepted
upstream or other reasons), forcing users to copy ebuilds in their
overlay and modifying the ebuild there. This turns out to be a hassle
every time the package receives an update.
I think you can redefine ebuild functions in /etc/portage/env/cat/pkg, so
you could out a custom src_unpack() in there. It should work if the ebuild
has no src_unoack, so you could do something like
src_unpack() {
unpack ${A}
epatch mypatch
}
I don't know how this would work with an existing src_unpack in the
ebuild, if you copied the existing function and added your patch.
--
Neil Bothwick
i *DId* rEaD tHE DoCS; ThaT'S WHy I'm conFuSeD!
signature.asc
Description: PGP signature
Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds
On Sun, 17 May 2009 09:42:20 +0100
Neil Bothwick n...@digimed.co.uk wrote:
I think you can redefine ebuild functions
in /etc/portage/env/cat/pkg, so you could out a custom src_unpack()
in there. It should work if the ebuild has no src_unoack, so you
could do something like
src_unpack() {
unpack ${A}
epatch mypatch
}
I don't know how this would work with an existing src_unpack in the
ebuild, if you copied the existing function and added your patch.
I use /etc/portage/bashrc for the same purpose. For instance, this is a
patch I'm tacking onto portage ATM:
if [[ ${CATEGORY}/${PN} == sys-apps/portage ]]
then
post_src_unpack() {
cd ${S}/bin
epatch /etc/portage/patches/misc-functions.patch
}
fi
As you can see, there are post_ and pre_ phases for all phase functions
which can be used to do fancy stuff like this.
I prefer /etc/portage/bashrc for this, since these hacks are usually
only needed for a short time, so having them all in one place for an
easy overview helps to keep the cruft down.
/loki_val
Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds
On Sun, 17 May 2009 12:13:27 +0200, Peter Alfredsen wrote:
As you can see, there are post_ and pre_ phases for all phase functions
which can be used to do fancy stuff like this.
Neat!
I prefer /etc/portage/bashrc for this, since these hacks are usually
only needed for a short time, so having them all in one place for an
easy overview helps to keep the cruft down.
Each to his own. I prefer a separate file for each program (or set of
programs), as it makes the function, and continued need, of each one
obvious. The same with /etc/portage/packages.{use,unmask,etc}.
--
Neil Bothwick
I've got a mind like a... a... what's that thing called?
signature.asc
Description: PGP signature
