Date: Mon, 21 Mar 2016 11:18:26 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: mat@FreeBSD.org Cc: ports@FreeBSD.org Subject: Re: gnome-post-install ordering Message-ID: <201603211818.u2LIIQJf060766@gw.catspoiler.org> In-Reply-To: <8EB21981928900BCB811B4B1@ogg.in.absolight.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Mar, Mathieu Arnold wrote:
> +--On 16 mars 2016 10:57:54 -0700 Don Lewis <truckman@FreeBSD.org> wrote:
> | I'm trying to debug why gtk-update-icon-cache isn't getting run when
> | the OpenOffice package is installed and ran into something that I don't
> | understand.
> |
> | The Makefile contains INSTALLS_ICONS=yes, which has the side effect of
> | setting USES+=gnome, USE_GNOME+=gtk-update-icon-cache, and
> | _USES_install+=690:gnome-post-install, and that target is responsible
> | for parsing ${TMPPLIST} and invoking gtk-update-icon-cache as needed.
> | I do see gtk-update-icon-cache in the dependency list in +MANIFEST, so
> | it appears that INSTALLS_ICONS=yes is being detected.
> |
> | It appears that things go wrong because I'm using the Makefile
> | post-install target to generate the plist. If I look at bsd.port.mk, I
> | see that _STAGE_SEQ contains 700:post-install. It looks to me like
> | gnome-post-install is getting run before the plist is generated, which
> | would explain why gnome-post-install isn't detecting any icons and not
> | invoking gtk-update-icon-cache.
> |
> | Why is gnome-post-install earlier than post-install, which at least some
> | ports use to do plist generation? Some ports do plist generation in
> | do-install, but that doesn't work if there are do-install option helpers
> | because those get run after the main do-install target.
> |
> | There is the TARGET_ORDER_OVERRIDE knob, but it is very lightly used.
>
> It is there exactly for the problem you have, change the order targets are
> run for one port.
>
> And it is very lightly used because it's only needed when you do some
> strange things that nobody else does ;-)
>
> For example, I just added it to devel/p5-ReadLine-TTYtter because I needed
> to run post-install before fix-perl-things. And it was ok to do it because
> it's a somewhat unique case.
I think that this particular instance is pretty subtle and may be more
widespread than you think. It has taken a long time for someone to
notice the problem with openoffice and file a PR. It looks like
editors/libreoffice also ran into this problem and "fixed" it by getting
rid of INSTALLS_ICONS and instead added a new tarket that adds the stuff
to TMPPLIST to run gtk-update-icon-cache, and adds that target to
${POST_PLIST}.
These other port Makefiles also use INSTALLS_ICONS and are doing
something with TMPPLIST, so they may also need to use
TARGET_ORDER_OVERRIDE:
editors/libreoffice4/Makefile
games/openttd/Makefile
games/rocksndiamonds/Makefile
multimedia/qmmp-qt5/Makefile
multimedia/qmmp/Makefile
multimedia/vlc/Makefile
x11-themes/gnome-icons-faenza/Makefile
The previous person to reply to this thread mentioned the case of
USES=python:autoplist, which generates the plist *very* late.
Running fix-perl-things after post-install seems like a very resonable
default. I think there are quite a few ports that use the default
do-install target and then fiddle around with the contents of
${STAGEDIR} in post-install.
> So, basically, you need to put:
>
> TARGET_ORDER_OVERRIDE= 650:post-install
>
> so that it's ran before gnome-post-install, and you're set.
Changing the sequence number of post-install isn't a good general fix
because that doesn't change the order of post-install-OPTION-on to match.
> Now, I don't have a problem with moving gnome-post-install after
> post-install (like, 710), which would also fix your problem, but it will
> need an exp-run to make sure nothing breaks.
gnome-post-install does several different things. I haven't looked to
see if all of them should be moved. Unfortunately I'm not sure that an
exp-run would pick up some of the more subtle breakage.
One of my concerns is that if we start using TARGET_ORDER_OVERRIDE all
over the place, that will make maintaining the framework a lot more
difficult. I think we need to try to get the defaults right for more
cases. That requires taking a step back and looking at when things get
done in the install phase and when are they needed. We need to be able
to define when all the files and directories need to be present in
${STAGEDIR}. We can't generate a dynamic plist until after that step.
Also, tasks like fix-perl-things shouldn't run until after that. How do
the last two items interact? When can we count on all files and
directories being in the plist? Parsing the plist, as is done by
gnome-post-install shouldn't be done until after that point.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201603211818.u2LIIQJf060766>