Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Mar 2016 14:21:24 -0700 (PDT)
From:      Don Lewis <truckman@FreeBSD.org>
To:        mat@FreeBSD.org
Cc:        ports@FreeBSD.org
Subject:   Re: gnome-post-install ordering
Message-ID:  <201603232121.u2NLLOa0069143@gw.catspoiler.org>
In-Reply-To: <2F936CEC82E5BACE893F56D6@ogg.in.absolight.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 23 Mar, Mathieu Arnold wrote:
> +--On 21 mars 2016 13:43:43 -0700 Don Lewis <truckman@FreeBSD.org> wrote:

> | I'd also like a target explicity for generating a dynamic plist that
> | runs after post-install.  Doing it in post-install works most of the
> | time unless you start using post-install option helpers to install
> | additional files.
> 
> No, dynamic plists are evil you don't check what end up in the package, and
> it's a mess.

Well, for openoffice-4 and openoffice-devel, which have six and seven
options (and probably expanding to eight) that affect the plist, I think
dynamic plists are a necessary evil.  Doing a parallel build on my
eight-core package building box takes about 1 1/4 hours.  That adds up
to more than 16 hours to verify the plist is correct for all the
options, assuming that they are all independent.  It's also not easy to
automate.  Either I have to use poudriere testport -c, which is
interactive, or I have to set up a bunch of make.conf files for the
different option sets and do a bunch of bulk -z set runs.  The latter
requires that all the prerequisites be built N times.  Even before
getting to that point, all those builds would have to be done in order
to generate the initial plist.

There have also been cases where I've made bug fixes that affect the
plist.  If I don't get the plist change correct the first time, then it
would add another 1 1/4 hours to the time it takes me to get a usable
package that I can install on a machine with a display so that I can
test the bug fix.

> I think you mean USE_PYTHON=autoplist, but the python autoplist feature
> only grabs stuff in the python module directory, so not icons.

Yes, I meant python.  Someone mentioned this PR:
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206019>.  I haven't
dug into that problem.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201603232121.u2NLLOa0069143>