Fernando Canizo schreef: > Hi all, > > I find a cute patch to mutt and to use it i modified the ebuild and > the pertinent files so now re-emerging mutt builds mutt with this > patch. Later i fixed the actual version of mutt so an upgrade cannot > erase it. > > What i would like to know is how can i do this i a 'gentoo way'. I > have listen that there are something called SLOTs, but never used so > far (never need them?) > > Or the only way is to propose the add of the patch to portage? >
Normally what one would do is place all modified ebuilds in your PORTDIR_OVERLAY (Portage directory overlay), which location can be set in /etc/make.conf (default is /usr/local/portage). /usr/local/portage has the same structure as the 'normal' portage tree, meaning that your ebuild would need to be placed in /usr/local/portage/mail-client/mutt/mutt-whatever.ebuild, and the currently-existing patch files would need to be copied to /usr/local/portage/mail-client/mutt/files, along with your additional patch. You would then use the command ebuild /usr/local/portage/mail-client/mutt/mutt-whatever.ebuild digest to create the manifest file (so that Portage knows what files are associated with the ebuild, and can calculate their MD5 sums to check them for corruption when emerging). At that point, because your ebuild is newer than the one in Portage, when you emerge mutt, your overlay ebuild is considered most recent, and you will see it when you attempt to emerge as follows (this example of course uses a different ebuild because mutt isn't in my overlay): emerge -pv unace ________________________________________________________________________________ cfg-update 1.7.1 : Building checksum index... (takes a few seconds) done! ________________________________________________________________________________ These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] app-arch/unace-2.2 178 kB [1] Total size of downloads: 178 kB Portage overlays: [1] /usr/local/portage [2] /usr/local/bmg-main As you see, the emerge data is footnoted with a [1], and the legend says that the ebuild comes from my first overlay, in /usr/local/portage. The thing is, that ebuilds in your overlay aren't overwritten or touched in any way by Portage, so you don't have to keep 'redoing' the ebuild every time you emerge sync. If the ebuild in Portage hasn't changed, your modified ebuild will always be newer; if the ebuild in Portage has changed, it's quite likely that whatever patch or functionality you were waiting for has been merged into the main tree upstream, or backported into the ebuild, so you have an easy migration path back into main Portage (and of course, if you care enough about the application and its patchset to modify an ebuild and put it in your overlay, checking the ChangeLog of any updated ebuilds is not an onerous task). If the program has been updated, but your patch still isn't there, then you can just copy and modify the updated ebuild and files. So that's the userland solution, but yes, if you want the patch included in Portage (which is likely to happen anyway, if it's a patch from upstream), the place to submit it for inclusion (preferably with the modified ebuild attached as well), would be bugs.gentoo.org (b.g.o). That's where most of the ebuilds in my overlay come from :) . The nice things about submitting the modified ebuild in this way are that 1) it makes less work for the devs (they don't have to write the ebuild, only check/correct yours); 2) if for some reason they are delayed in, or don't want to, include the ebuild into Portage (as is the case with the unace ebuild in the example above), it's still available for those crazy or desperate enough to want to use it anyway. 3) it helps people willing to debug to do so-- I'm fairly sure that those of us who contributed to debugging the taskjuggler ebuild helped the ebuild become better, faster, so that it was recently included in Portage (though I can't compile it for some reason, gotta revisit that bug, actually). Hope that helps answer your question. Holly -- gentoo-user@gentoo.org mailing list
