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
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
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
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
and CDEPEND would be cool as well for those packages that can use another but
dont care other wise
PDEPEND works wonderfully! Merged the masked copy of portage, have had 0
Ok... So I can't just close a bug now... I actually have to comment on it. Sheesh.
Done and done. ;)