Summary: | PORTDIR_OVERLAY requires duplicating files from the original portage_dir | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Peter S. Mazinger <ps.m> |
Component: | [OLD] Core system | Assignee: | Portage Tools Team <tools-portage> |
Status: | RESOLVED REMIND | ||
Severity: | enhancement | CC: | h.mth, michael |
Priority: | Lowest | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Small bash script to symlink files dir into an overlay
Same thing, but with two bug fixes ;) evil hack to use user_src_{unpack,compile,install} |
Description
Peter S. Mazinger
2004-06-11 14:52:46 UTC
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... |