public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Auto-patching ebuilds themselves  Was: Eclass vs EAPI For Utility Functions (Patching/etc)
Date: Sun, 15 Jun 2014 23:36:15 +0000 (UTC)	[thread overview]
Message-ID: <pan$4c193$5a45ad70$1335b484$60fc9f10@cox.net> (raw)
In-Reply-To: CAGfcS_kix1enpz4uwj5tO-Qeeqrp=8tKWjdMiC1QuUR-g8R4Tg@mail.gmail.com

Rich Freeman posted on Sun, 15 Jun 2014 07:00:15 -0400 as excerpted:

> Besides, I think user-patches are a GREAT feature to have, and one I use
> all the time (without even thinking about it if a package with a patch
> gets rebuilt).  As I said in the meeting, if we were selling Gentoo to
> make money, it would be the sort of feature that you'd advertise.  Why
> make it hard to use such a distinctive advantage of a source-based
> distro?

Agreed with everything, but focusing on the above as a jump-off point 
for...

A similarly great feature to have would be epatch-ebuild.  Back when 
gentoo/kde was trying to dump IUSE=semantic-desktop[1], I was doing 
enough ebuild patching with enough churn in the ebuilds[2] that manual
per-ebuild patching was simply no longer feasible.  It can be noted that 
normal sources patching (as epatch) would NOT work here, at least not 
easily, because it was the ebuilds themselves that were forcing the 
various semantic-desktop related config options on and forcing 
dependencies to match, so it was the ebuilds themselves that needed that 
patched back out.

I ended up with an /etc/portage/patches.ebuild that mirrored 
/etc/portage/patches in functionality, using a sync script that
download-updated both the gentoo tree and the layman-managed overlays, 
then _automatically_ applied the patches from the patches.ebuild tree and 
redigested the ebuilds[3], then regenerating cache to account for the 
changes.  The _automatic_ bit being critical as at that point I was 
handling enough of them that doing it manually would not have been fun.

Talk about a feature worth advertising, the user-level ability to 
automatically live-patch ebuilds by simply dropping a patch in the 
appropriate location just like we do sources was and remains great, 
definitely something I'd love to see in the PMs at some point. =:^)

As we've found with user-epatched sources, this should greatly simplify 
deployment of experimental patches.  Just attach the patch to the bug and 
tell the user what directory to drop it in, and no more worries about 
having to tell users what to edit or how to do manual patching, in 
ordered to test a fix. =:^)

---
[1] Dropping IUSE=semantic-desktop: Something I'm /ever/ so glad gentoo/
kde changed their minds on. =:^)

[2] The ebuilds in question were from the gentoo/kde overlay, before they 
reached the tree.  That overlay and the ebuilds in it get a *LOT* of 
churn!

[3] Redigesting:  As I run live-sources kde there were few source 
tarballs to redigest, only the ebuilds.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman



  parent reply	other threads:[~2014-06-15 23:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-15 11:00 [gentoo-dev] Eclass vs EAPI For Utility Functions (Patching/etc) Rich Freeman
2014-06-15 12:14 ` Ciaran McCreesh
2014-06-15 13:30 ` Michał Górny
2014-06-19 22:05   ` [gentoo-dev] " Steven J. Long
2014-06-19 22:22     ` Rich Freeman
2014-06-15 23:36 ` Duncan [this message]
2014-06-16  9:54 ` [gentoo-dev] " Pacho Ramos
2014-06-19 17:03 ` William Hubbs
2014-06-19 17:53   ` Rich Freeman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$4c193$5a45ad70$1335b484$60fc9f10@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox