Applying patches without needing overlays and modifying ebuilds

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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?


Reply | Threaded
Open this post in threaded view
|

Re: 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.

Reply | Threaded
Open this post in threaded view
|

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.


Reply | Threaded
Open this post in threaded view
|

Re: Re: Applying patches without needing overlays and modifying ebuilds

Mike Kazantsev
On Sun, 17 May 2009 10:20:33 +0300
Nikos Chantziaras <[hidden email]> 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

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Applying patches without needing overlays and modifying ebuilds

Graham Murray
In reply to this post by Nikos Chantziaras
Nikos Chantziaras <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Applying patches without needing overlays and modifying ebuilds

Neil Bothwick
In reply to this post by Nikos Chantziaras
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 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Applying patches without needing overlays and modifying ebuilds

Peter Alfredsen-3
On Sun, 17 May 2009 09:42:20 +0100
Neil Bothwick <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Applying patches without needing overlays and modifying ebuilds

Neil Bothwick
In reply to this post by Peter Alfredsen-3
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 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Applying patches without needing overlays and modifying ebuilds

Pavel Sanda
In reply to this post by 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?  
>
>   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