Re: [Pan-users] [Gentoo] custom pan-9999 ebuild Was: Articles Pan Can't Read

[Duncan]

Nicolas Richard posted on Wed, 17 Aug 2011 11:00:47 +0200 as excerpted:

> Le 11/08/2011 11:22, Duncan a écrit :
>> In my personal overlay I maintain a pan-9999 ebuild that, at least
>> currently, has USE flags to either official gnome git repo, [or...]
> 
> This is far more complex than my own ebuild (which is the official one +
> an EGIT_PATCHES variable set for the small patch I wanted to apply).
> I am a newbie to gentoo. Still, I'll be happy to read and use your
> ebuilds if you decide to publish them.

OK, here's my updated pan-9999.ebuild, along with a well commented 
pan-9999 file that can be placed in /etc/portage/env/net-nntp/ , to 
control the git repo and branch used.

Note that I'm testing hmueller's (aka imhotep82's) attachment code with 
no encoding, since both files are plain text and thus shouldn't need 
encoded.  I guess we'll see how it works. =:^)



The changes of note from the in-tree pan-9999.ebuild are:

1) Switch to EAPI-4 .  (This was needed in an earlier iteration but 
shouldn't be now.  I could have switched back to EAPI-3, but why would I?

2) USE=gtk3 flag.  With this on, it builds against and requires gtk3.  
However, note that I haven't checked the deps in this case.  With it off, 
the way I use it here and thus the tested way, it builds and deps against 
gtk2.  (For a period the khaley git build built/depended on gtk3 by 
default, so I had to add a gtk3 config parameter and simply hooked it up 
to this flag to turn it off here.  When firefox and claws-mail get gtk3 
versions I'll probably upgrade all three at once, potentially testing 
gtk3 dependencies at that point, if someone with it already installed 
doesn't post updates before then.)

3) Uses git-2.eclass instead of the deprecated git.eclass.

4) gnome-base/gnome-common dependency.  This is pulled in for an auto-
tools script (IDR which) needed in the git version, but not when built 
from a proper release tarball.

5) Of course, the set of "if unset, use these defaults" variable tests, 
to match the variables set in the corresponding env file.



The pan-9999 env file as attached is set to repo=hmueller , 
EGIT_BRANCH=master.  If you want the defaults, simply comment those 
settings or don't install that file to /etc/portage/env/net-nntp/pan-9999 
as intended.  Or set them as you like, based on the comments or comments 
you see here, or your own research, or...

(Alternatively, to retain the defaults while keeping the repo file for 
reference, install it so it deliberately breaks the name-pattern, say
/etc/portage/env/net-nntp/pan-9999.example, or the like, thus keeping it 
around for reference without actually activating it.)



Meanwhile, for patching, here's a nice trick already used in some but not 
all ebuilds.  Use the epatch_user function from eutils.eclass.  This 
allows placing patches to be applied in /etc/portage/patches/category/pkg-
namish/patchname (see the comments in eutils.eclass for the pgk-namish 
specifics, but basically, the first of $PF|P|PN, in that order, see the 
ebuild (5) manpage for the meaning of those vars).

Since the function is specifically written to only apply the patches once 
even if it's called multiple times (as from the ebuild itself and several 
inherited eclasses), it's possible to simply add the following to your 
/etc/portage/bashrc file, and have it do the expected for /most/ packages 
(the ones that inherit eutils either directly or thru other directly 
inherited eclasses, EAPI-2 and newer since src_prepare was defined in 
EAPI-2).  One can't inherit eutils from the bashrc, unfortunately (I 
tried and got errors), so the trick only works on packages that inherit 
it either directly or indirectly, but that seems to be most of the 
packages I've needed to patch, at least.

In /etc/portage/bashrc add this hook (create the file if you don't have 
one yet):

post_src_prepare () {
        epatch_user
}


Then you can just add your patches to...

/etc/portage/patches/net-nntp/pan-9999/

... and get them automatically applied.  (The pan ebuild inherits eutils 
thru the base.eclass inherit, so it works.)  No more modifying and re-
manifesting the ebuild every time you wish to change the patches you 
apply! =:^)



OK, here's posting to see how the attachments come out! ... Double-
checked, yes, they're listed in the file-queue so I've not forgotten to 
attach them. =:^/

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