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
next prev 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