In the course of working on ebuilds, I am encountering situations where a PDEPEND, that is, a post depend, would really help. For instance, applications that cannot be patched prior to install, but that post install can be fixed (perl 5.6.1 in this case). Or applications that have a sub component that if they try to install, they break the sandbox, but that could easily be emerged after the fact if the were a seperate emerge process. If there is already a mechanism in place for this and I've missed, just let me know, not trying to complicate efforts. Thanks!
you could either disable the sandbox or use the pkg_postinst function `man 5 ebuild` for a list of functions ebuild supports
Then either portage .27 is broken, or the pkg_postinst does not support emerging. I just did a test ebuild, added an emerge someport/somepackage in the pkg_postinst block, and it never even ran that portion (nohup emerge -d to get that output).
I should clarify - this is not for file system cleanups, such as moving some things around once the ebuild is done installing out of the sandbox. This is a general requirement/request/idea to be able to call an emerge following the main emerge, to correct items that can't be patched prior to the final ebuild, working (in my head, at least) much the same way a DEPEND/RDEPEND would call the other ebuilds prior to the main ebuild.
i really dont see what you're going for :) the way i see it is that pkg_postinst is used to do everything on the live filesystem that needs to be done ... you say correct a few things, i'd throw code in there to do so ...
pkg_postinst will not install an ebuild. I've tested it. For example: the perl 5.6.1 ebuild that we support comes with a perl module called ExtUTILS. The built in version is broken, you need to replace it with a new one. The ideal way to do that would be to emerge a new one once your perl build is complete. You cannot replace it until afer perl is installed. However, if it were possible to do a post depend, you could say that after the perl ebuild is complete, emerge dev-perl/extutils, which would ideally be the corrected copy of that module. If there is a mechanism aside from pkg_postinst, or syntax that I am not seeing in any of the man pages, tell me, I'm easy =:)
I think this can be done with an idea I've been tossing around called conditional dependencies. CDEPEND=">foo/bar-2.0" would upgrade foo/bar to >2.0 only if it happens to be installed, but will not install it if it isn't installed. If we do this *after* the actual package that contains CDEPEND is merged, will this solve the issue?
Yes, I think so (though in the case of the perl module, found a work around abusing the eclass for perl-modules). Sorry I didn't respond here sooner, got sidetracked.
actually, we need CDEPEND but also the possibility of a PDEPEND which will, no matter if the package is installed or not, install another package after the current one. This would fix perl and perl-module issues.
i could use both the PDEPEND and CDEPEND for xemacs-packages the dependancies for xemacs packages are way too convoluted and need some serious work but thats another story PDEPEND would be useful for installing packages for xemacs after it gets installed like the current efs xemacs-base and mule-base install that gets done in the current ebuild and CDEPEND would be cool as well for those packages that can use another but dont care other wise
Carpaski, PDEPEND works wonderfully! Merged the masked copy of portage, have had 0 problems.
Ok... So I can't just close a bug now... I actually have to comment on it. Sheesh. Done and done. ;)
