| 1 |
Fernando Canizo schreef: |
| 2 |
> Hi all, |
| 3 |
> |
| 4 |
> I find a cute patch to mutt and to use it i modified the ebuild and |
| 5 |
> the pertinent files so now re-emerging mutt builds mutt with this |
| 6 |
> patch. Later i fixed the actual version of mutt so an upgrade cannot |
| 7 |
> erase it. |
| 8 |
> |
| 9 |
> What i would like to know is how can i do this i a 'gentoo way'. I |
| 10 |
> have listen that there are something called SLOTs, but never used so |
| 11 |
> far (never need them?) |
| 12 |
> |
| 13 |
> Or the only way is to propose the add of the patch to portage? |
| 14 |
> |
| 15 |
|
| 16 |
Normally what one would do is place all modified ebuilds in your |
| 17 |
PORTDIR_OVERLAY (Portage directory overlay), which location can be set |
| 18 |
in /etc/make.conf (default is /usr/local/portage). |
| 19 |
|
| 20 |
/usr/local/portage has the same structure as the 'normal' portage tree, |
| 21 |
meaning that your ebuild would need to be placed in |
| 22 |
/usr/local/portage/mail-client/mutt/mutt-whatever.ebuild, and the |
| 23 |
currently-existing patch files would need to be copied to |
| 24 |
/usr/local/portage/mail-client/mutt/files, along with your additional patch. |
| 25 |
|
| 26 |
You would then use the command |
| 27 |
|
| 28 |
ebuild /usr/local/portage/mail-client/mutt/mutt-whatever.ebuild digest |
| 29 |
|
| 30 |
to create the manifest file (so that Portage knows what files are |
| 31 |
associated with the ebuild, and can calculate their MD5 sums to check |
| 32 |
them for corruption when emerging). |
| 33 |
|
| 34 |
At that point, because your ebuild is newer than the one in Portage, |
| 35 |
when you emerge mutt, your overlay ebuild is considered most recent, and |
| 36 |
you will see it when you attempt to emerge as follows (this example of |
| 37 |
course uses a different ebuild because mutt isn't in my overlay): |
| 38 |
|
| 39 |
emerge -pv unace |
| 40 |
________________________________________________________________________________ |
| 41 |
|
| 42 |
cfg-update 1.7.1 : Building checksum index... (takes a few seconds) done! |
| 43 |
________________________________________________________________________________ |
| 44 |
|
| 45 |
|
| 46 |
These are the packages that I would merge, in order: |
| 47 |
|
| 48 |
Calculating dependencies ...done! |
| 49 |
[ebuild R ] app-arch/unace-2.2 178 kB [1] |
| 50 |
|
| 51 |
Total size of downloads: 178 kB |
| 52 |
Portage overlays: |
| 53 |
[1] /usr/local/portage |
| 54 |
[2] /usr/local/bmg-main |
| 55 |
|
| 56 |
As you see, the emerge data is footnoted with a [1], and the legend says |
| 57 |
that the ebuild comes from my first overlay, in /usr/local/portage. |
| 58 |
|
| 59 |
The thing is, that ebuilds in your overlay aren't overwritten or touched |
| 60 |
in any way by Portage, so you don't have to keep 'redoing' the ebuild |
| 61 |
every time you emerge sync. |
| 62 |
|
| 63 |
If the ebuild in Portage hasn't changed, your modified ebuild will |
| 64 |
always be newer; if the ebuild in Portage has changed, it's quite likely |
| 65 |
that whatever patch or functionality you were waiting for has been |
| 66 |
merged into the main tree upstream, or backported into the ebuild, so |
| 67 |
you have an easy migration path back into main Portage (and of course, |
| 68 |
if you care enough about the application and its patchset to modify an |
| 69 |
ebuild and put it in your overlay, checking the ChangeLog of any updated |
| 70 |
ebuilds is not an onerous task). |
| 71 |
|
| 72 |
If the program has been updated, but your patch still isn't there, then |
| 73 |
you can just copy and modify the updated ebuild and files. |
| 74 |
|
| 75 |
So that's the userland solution, but yes, if you want the patch included |
| 76 |
in Portage (which is likely to happen anyway, if it's a patch from |
| 77 |
upstream), the place to submit it for inclusion (preferably with the |
| 78 |
modified ebuild attached as well), would be bugs.gentoo.org (b.g.o). |
| 79 |
That's where most of the ebuilds in my overlay come from :) . |
| 80 |
|
| 81 |
The nice things about submitting the modified ebuild in this way are that |
| 82 |
|
| 83 |
1) it makes less work for the devs (they don't have to write the ebuild, |
| 84 |
only check/correct yours); |
| 85 |
|
| 86 |
2) if for some reason they are delayed in, or don't want to, include the |
| 87 |
ebuild into Portage (as is the case with the unace ebuild in the example |
| 88 |
above), it's still available for those crazy or desperate enough to want |
| 89 |
to use it anyway. |
| 90 |
|
| 91 |
3) it helps people willing to debug to do so-- I'm fairly sure that |
| 92 |
those of us who contributed to debugging the taskjuggler ebuild helped |
| 93 |
the ebuild become better, faster, so that it was recently included in |
| 94 |
Portage (though I can't compile it for some reason, gotta revisit that |
| 95 |
bug, actually). |
| 96 |
|
| 97 |
Hope that helps answer your question. |
| 98 |
Holly |
| 99 |
-- |
| 100 |
gentoo-user@g.o mailing list |
Archives