if only an ebuild is copied from the original and changed in the overlay directory, then following vars are not interpreted correctly DISTDIR/FILESDIR, these should allow to place new or replacement files to distfiles, or the overlay package/files directory, but if the ebuild used some files from the earlier FILESDIR, it won't be found, so all the needed files have to be copied to the new location as well, distfiles is ignored completely also Manifest and digest-* are required, although only digest makes really sense if some source packages change their md5sum (but it should not be mandatory) the profiles handling does not work at all (non-stackable) from this directory Reproducible: Always Steps to Reproduce: 1. create an overlay dir and copy gcc-ebuild there 2. set the overlay dir in make.conf 3. run emerge gcc Expected Results: it should interpret digest if it is present instead of the original one it should find files in the overlay and the original dir it should find files in overlay distfiles if a file is found in the overlay dir as replacement for the original profile file, this should be used instead of the original
How the heck would that work??? Ebuilds use ${FILESDIR}/blah.patch, for example.
What you're asking for provides little benefit, and a crapload of code complexity. The filesdir is specific to the package definition- by definition, I mean the repository/category/package directory. You're asking for portage to be aware of all packages w/ the same cat/name across repositories, and treat their files dir as one directory. It's a change from how things are done, and it's a pita to implement... personally, I just use a script, I wouldn't want portage to do what you're asking- if I'm testing a modification to a patch in an overlay, when I emerge a package out of the tree (non-overlay), I expect it to use the patch that's in the tree- I don't want the possibility of portage trying to be helpful, and grabbing the potentially borked patch in my overlay that happens to have the same name. portage crew? your thoughts?
i think it's kind of a nice idea ... search path for $FILESDIR ... the problem is that i think it could *easily* introduce obscure bugs
what do you think of making links in the overlay directory to the files used in the respective ebuild (looking for FILESDIR) when ebuild digest is running the distfiles would need inverse link from the overlay_dir to /usr/portage/distfiles, although I do not like the distfiles links solution
Strikes me as an idea for a script to add to gentoolkit{,-dev}.
Dev-portage won't be doing this. A tool to simplify your life might be possible. If tools-portage is interested, they can take it.
Carpaski says it all.
Created attachment 76221 [details] Small bash script to symlink files dir into an overlay
Created attachment 76222 [details] Same thing, but with two bug fixes ;)
I have an alternative idea. What I see is that there are pre_* and post_* functions to common functions of an ebuild. Now why do not add user_* stub functions to portage that a user can set in a overlay like PORTDIR_OVERLAY which are run after pre_*, post_* and common functions. There the user can do all his/her evil things. Let a variable like OFILESDIR point to the filesdir of an overlay. Is there a flag like '-R' for epatch to unapply patches from FILESDIR. This would be nice to have for that.
Created attachment 81596 [details, diff] evil hack to use user_src_{unpack,compile,install} Set USERFUNC_OVERLAY="/path/to/overlay" in /etc/make.conf. Create paths like for PORTDIR_OVERLAY - /path/to/overlay/category/PN/files. user_src_* executes after src_* OFILESDIR points to /path/to/overlay/category/PN/files Why user_src_* functions? Hell, sometimes I just want to add patches. And just for that I have to copy the whole subtree. That is horrible. You just add /path/to/overlay/category/PN/P.ebuild New patches go into /path/to/overlay/category/PN/files (like epatch ${OFILESDIR}/your.diff, ${FILESDIR} being still valid) You can overwrite a single function from ebuild to do selective replacements. No more the need to copy the complete subtree. This sounds evil. ;)
You can use /etc/portage/bashrc for that already.
While this idea is not without merit, it doesn't look like it's going to be put in an official Gentoo package any time soon. Please check back in a couple more years...
