I need the ability to provide custom replacements for sections of ebuild files. I don't want to replace the whole file, and I don't want to have to copy files into $PORTDIR_OVERLAY and edit them every time a new version of the package is released. Take for example the configuration section of the net-mail/courier ebuild.It contains something like: ./configure \ --prefix=/usr \ --disable-root-check \ and so on. I don't want to change the whole ebuild file, just a few lines of it. Let's say we surround this with arbitrary tags... #REPLACE-1 ./configure \ --prefix=/usr \ #END-REPLACE-1 Now, in the /etc/make.profile directory we have patch files, e.g. in /etc/make.profile/net-mail/courier we have this: #REPLACE-1.1 ./configure \ --prefix=/usr/local \ --disable-root-check \ --with-mail-user=courier #END-REPLACE-1.1 Every time a later version of courier is released, the same patch will be applied without user intervention. If The ebuild maintainer wants to drastically change the way the ebuild is managed, or simply wants to add new options to this section, all they have to do is change the tag names (#REPLACE-1.1 becomes #REPLACE-1.2) so that emerge can alert the user that their patch needs attention. What do you think? -- Tim Hosking
*** Bug 7858 has been marked as a duplicate of this bug. ***
Amendment: I said: #REPLACE-1 ./configure \ --prefix=/usr \ #END-REPLACE-1 I meant: #REPLACE-1.1 ./configure \ --prefix=/usr \ #END-REPLACE-1.1 Minor change but you get the picture
I think it would also be good to implement a command line option for changing the configure flags. This way users can test out various options before deciding on something to put in their patches directory. In this example, it would look something like `emerge courier unconfigure="--prefix=/usr" configure="--prefix=/usr/local --with-mail-user=courier` This feature would be very useful for configure options such as these that USE variables can't, or shouldn't, exist for.
That would be a cool thing! I need that for courier as well.
It would be nice if you could change configure parameters for an ebuild with a file either in portage dir or in PORTDIR_OVERLAY. lets say it is called configure_options and contains: remove --prefix add --prefix=/otherpartition/onbiggerdisk add --disable-root-check
or, as I wrote in #6677 (PORTAGE_OVERLAY suggestions): get rid of PORTAGE_OVERLAY have emerge look for a *.local file in the portage directory tree (e.g. net-www/mozilla/) and use that to OVERRIDE settings in the (unmasked and/or latest depending upon ~STABLE flag) ebuild file
*** Bug 13042 has been marked as a duplicate of this bug. ***
You realize that this feature would create a maintenance nightmare for gentoo devs ?
Yes, I know just what kind of maintenance problem this entails, I suspect a number of us do. You see, the gentoo default install options do not work for everyone, and some of us need to kludge things for lots of packages. It gives us far more maintenance issues, because we have to futz with it every build. An alternate idea on this would be to allow us to suspend the build right before 'make', so that we could modify the config by hand. (Yes, I know, technically speaking, we do have control-Z, but that requires us to actually pay attention to the entire emerge, so that we manage to suspend the build each time we need to.) (Back when I at least had the illusion of having free time, I tried making a distro around the concept of doing exactly what this request is trying to do. Unfortunately, I only had the illusion of free time; after five months, I'd only managed to put about 8 hours into it.)
EXTRA_ECONF provides similar functionality... Beyond that, this is particularly nasty from the standpoint of ensuring a pkg's configure options match out to it's USE controlled rdepends. That would need to be addressed... Better question, what exactly do you need, that requires the ability to basically mangle critical sections of an ebuild? Meanwhile, slapping this shut due to EXTRA_ECONF... still would like to know exactly what you're attempting, since a better solution might be available/doable/preferable.
