As part of GLEP #11, we're introducing a two-stage install process for all web-based applications. This process is managed by the webapp.eclass, and the webapp-config tool. The ebuild creates an intermediate install, which Portage puts under /usr/share/webapps. Then, the user runs webapp-config to create the final working install under /var/www. This two-stage process is essential for supporting virtual hosting - controlled by the 'vhosts' USE flag. Users who do not have 'vhosts' in their USE flags still go through the two-stage install process. The difference is that webapp.eclass automatically calls webapp-config in pkg_postinst(). webapp-config can run in install (-I) or upgrade (-U) mode. webapp.eclass needs a reliable way to tell which of these switches it should be using. The suggested way - calling has_version ${CATEGORY}/${PN} - does not work when a package changes category. Consider the following scenario: user installs net-www/foobar we move net-www/foobar to www-blog/foobar user runs 'emerge -u' has_version fails, because ${CATEGORY} is set to www-blog We need a way, in pkg_postinst(), to 100% reliably tell whether the ebuild is an upgrade or a fresh install. We don't need to know which category it used to be in - we're not supporting two or more webapps with the same ${PN}. A simple IS_UPGRADE=0|1 type solution is all we need. I've marked this as a blocker because this is holding up the roll-out of GLEP #11. We can't roll out improved ebuilds if our users can't reliably upgrade their packages. Best regards, Stu
"has_version foo/bar" should work because portage updates the names of any installed packages when packages are moved. Can you give it a try and confirm that it doesn't work?
Nick seemed to think that only binary packages got re-categorised. Any suggestions for how to test this without actually moving a package in the CVS tree? If not, where can I find epkgmove? It doesn't seem to be in gentoolkit, nor in the portage category :( Thanks, Stu
Created attachment 30048 [details] Test Case I used the attach ebuild and following commands to ensure that portage does update the installed package database (although the ebuild wasn't renamed, which is a different bug). However, this showed a different problem. Using "has_version ${CATEGORY}/${PN}" from pkg_postinst will always return 1 as the version being installed has already been added to the database. bash-2.05b# emerge movetest Calculating dependencies ...done! >>> emerge (1 of 1) app-portage/movetest-1.0 to / >>> Unpacking source... >>> Source unpacked. Compile >>> Install movetest-1.0 into /var/tmp/portage/movetest-1.0/image/ category app-portage Install man: prepallstrip: strip: >>> Completed installing into /var/tmp/portage/movetest-1.0/image/ >>> Merging app-portage/movetest-1.0 to / Post Install *** Found! *** !!! ERROR: app-portage/movetest-1.0 failed. !!! Function pkg_postinst, Line 21, Exitcode 0 !!! (no error message) !!! FAILED postinst: 1 bash-2.05b# ls /var/db/pkg/app-portage/movetest-1.0/ CATEGORY CFLAGS CXX LICENSE PROVIDE environment.bz2 CBUILD CHOST CXXFLAGS PDEPEND RDEPEND movetest-1.0.ebuild CC CONTENTS DEPEND PF SLOT CDEPEND COUNTER IUSE PKGUSE USE bash-2.05b# echo "move app-portage/movetest app-portage/testmove" >> /usr/portage/profiles/updates/1Q-2004 bash-2.05b# emerge Performing Global Updates: /usr/portage/profiles/updates/1Q-2004 (Could take a couple minutes if you have a lot of binary packages.) .='update pass' *='binary update' @='/var/db move' s='/var/db SLOT move' S='binary SLOT move' ..........................................@ emerge: please tell me what to do. Usage: emerge [ options ] [ action ] [ ebuildfile | tbz2file | dependency ] [ ... ] emerge [ options ] [ action ] < system | world > emerge < sync | info > emerge --resume [ --pretend | --ask | --skipfirst ] emerge help [ system | config | sync ] Options: -[abcCdDefhikKlnoOpPsSuUvV] [--oneshot] [--noconfmem] [--columns] [--nospinner] Actions: [ clean | depclean | inject | prune | regen | search | unmerge ] For more help try 'emerge --help' or consult the man page. bash-2.05b# ls /var/db/pkg/app-portage/ testmove-1.0 bash-2.05b# ls /var/db/pkg/app-portage/testmove-1.0/ CATEGORY CFLAGS CXX LICENSE PROVIDE environment.bz2 CBUILD CHOST CXXFLAGS PDEPEND RDEPEND movetest-1.0.ebuild CC CONTENTS DEPEND PF SLOT CDEPEND COUNTER IUSE PKGUSE USE
Where do we stand with this bug? We still need this functionality. Many thanks, Stu
a) both PKGDIR and /var/db/pkg will be updated during global updates. b) you could workaround the has_version problem by calling it in pkg_setup() and store the result in a file in $T, then test for that in pkg_postinst(). It's a kludge, but should work. c) there isn't a standard way to test for that yet, easiest would probably to move the relevant code from emerge to portage and set a variable MERGE_MODE or so, comments?
b) you could workaround the has_version problem by calling it in pkg_setup() and store the result in a file in $T, then test for that in pkg_postinst(). It's a kludge, but should work. Could you post an example code snippet that does this? It would be very useful if it would respect SLOT as well. I tried to implement that for the motif ebuilds, but failed.
Created attachment 72444 [details, diff] Add a PORTAGE_PRIOR_VERSIONS var Would something like this work? The var is only available in pkg_{pre,post}inst.
Is there still a need for anything here or can this be closed? As for a code example (untested): pkg_setup() { if has_version {CATEGORY}/${PN}; then touch ${T}/is_upgrade fi } pkg_postinst() { if [ -e ${T}/is_upgrade ]; then # do upgrade stuff else # do first install stuff fi }
Can we rely on ${T} not being emptied in between? We worked around this problem by having webapp.eclass use webapp-config to detect whether the package was already installed or not. It works, but it's a shame that Portage can't export this information natively to the ebuild/eclass. Best regards, Stu
*** This bug has been marked as a duplicate of bug 273646 ***
