[gentoo-user] Applying patches without needing overlays and modifying ebuilds

[gentoo-user] Applying patches without needing overlays and modifying ebuilds

[Nikos Chantziaras]

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

[Saphirus Sage]

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.

[gentoo-user] Re: Applying patches without needing overlays and modifying ebuilds

[Nikos Chantziaras]

Saphirus Sage wrote:
> 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.

The point I'm trying to make is applying patches without even touching 
the ebuild.

Re: [gentoo-user] Re: Applying patches without needing overlays and modifying ebuilds

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

On Sun, 17 May 2009 10:20:33 +0300
Nikos Chantziaras <realnc@arcor.de> wrote:

> >> 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
...
> >> Can someone think of a way to set up something like this?

I'd suggest passing the list of patches thru the environment - it
should be much easier to implement than commandline. Like this:

  MY_PATCHES='j-random-hack.patch' emerge media-video/smplayer

Then you can edit /usr/portage/eclass/base.eclass, adding processing of
this var and all the patching you need to "base_src_util" function,
right after "unpack ${A}".
In fact, I think I've seen such thing already implemented somewhere,
but prehaps it's just a by-product of my imagination.

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds

[Graham Murray]

Nikos Chantziaras <realnc@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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

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!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds

[Peter Alfredsen]

On Sun, 17 May 2009 09:42:20 +0100
Neil Bothwick <neil@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

[gentoo-user] Re: Applying patches without needing overlays and modifying ebuilds

[Nikos Chantziaras]

Peter Alfredsen wrote:
> On Sun, 17 May 2009 09:42:20 +0100
> Neil Bothwick <neil@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.

Thanks.  I already have a /etc/portage/bashrc in place, which pulls 
packages out of /etc/portage/package.icc to be compiled with Intel C++. 
  I'll try to use the same mechanism to pull patches from 
/etc/portage/package.patch for packages listed there.

Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds

[Pavel Sanda]

> 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