Fernando Canizo schreef: > El 30/ago/2005 a las 22:36 -0300, Holly me decía: > >>Normally what one would do is place all modified ebuilds in your >>PORTDIR_OVERLAY ... > > > Thank you very much. You should take advice from Nick and make it a howto. I'm > surely going to translate to spanish and put it in my blog, maybe i would add > something if i get to make it work ;)
Thanks, and more power to you! > > I can't make it work but it's after 2 AM and maybe i just need to read some > docs. > > ebuild says: > > # ebuild /usr/local/portage/mail-client/mutt/mutt-conan-1.5.8-r2.ebuild digest > !!! aux_get(): ebuild path for 'mail-client/mutt-conan-1.5.8-r2' not > specified: > !!! None > !!! aux_get(): ebuild path for 'mail-client/mutt-conan-1.5.8-r2' not > specified: > !!! None > doebuild(): aux_get() error reading mail-client/mutt-conan-1.5.8-r2; aborting. The probelm here is (likely) that the name of the package (for the purposes of the ebuild) is 'mutt-conan', not mutt. The format for an overlay folder (like Portage) is cat-egory/package-name/package-name.and-version.ebuild so your ebuild should likely be in /usr/local/portage/mail-client/mutt-conan/mutt-conan-1.5.8-r2.ebuild rather than just 'mutt'. I get caught by that one all the time > > >>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). > > > I did it by hand, first time, when modified ebuild in /usr/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. > > > Cool, that's what i wanted. But i have to fix version in > /etc/portage/packages.mask if i want to forbid mutt being upgraded, have i? Not necessarily, because your package is called mutt-conan, not mutt. So all you have to do is not emerge mutt-- as long as you don't emerge a package that depends on mutt, which I don't know if there are any, you should be good to go. If your package was called mutt, you could mask all versions above the one you used, just like you would for any other ebuild, but I wouldn't do that myself, because then how will you know if the package was upgraded (possibly folding in your changes, or, if not, nonetheless incorporating features that you might want in your modified ebuild anyway). In other words, not masking the original package makes it easier to know when to update your overlay ebuild, imo. You might want to check your virtuals, though, and/or package.provided, to let Portage know that "mutt" is provided by "mutt-conan". > > >>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). > > > Well, i've not synced for a while, but i think sooner or later will do. > Emm... the patch isn't going to be upstream soon if ever. I asked for some > behaviour in mutt-user mailing list and someone give me this patch. Now i'm > asking there to put it in the core, but that could not happen. Is this a behaviour that a significant portion of the mutt userbase might want? Or are you just weird ;) ? If you're just weird, use your overlay and be happy. If you think it might be useful to other mutt users, submit it to b.g.o (make sure to explain the circumstances so they don't go irritating upstream with a patch that upstream has no interest in). Or, if there's an unofficial 'mutt users' site or two, you could offer it to them to host, so that non-gentoo mutt users would have access to it as well. Or, if there's some way to 'modularize' mutt, you could look into turning the patch into a 'plugin' (if such things exist, I know nothing about mutt), so that it would be optional to those who wanted to use it. > > >>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). > > > Well, maybe i try it, the patch is so simple that even if never gets to mutt > core, i think it wouldn't do any damage to maintain it in gentoo. I can do > that. :) Yes, you can. Isn't Gentoo great? Did you know yesterday that "even you" could contribute to development? $DEITY, I *love* that.... ! Holly -- gentoo-user@gentoo.org mailing list
