Date: Thu, 22 Apr 2010 10:20:09 -0700 From: Charlie Kester <corky1951@comcast.net> To: freebsd-ports@freebsd.org Subject: Re: Dynamic plists Message-ID: <20100422172009.GA27597@comcast.net> In-Reply-To: <u2ob025ceb71004220848z7a224afw1de8b823a5761761@mail.gmail.com> References: <x2ub025ceb71004211645lf30a0fb9o5cebd612c3a28527@mail.gmail.com> <4BCFEA35.8070109@bsdforen.de> <20100422065709.GA33521@e.0x20.net> <u2ob025ceb71004220848z7a224afw1de8b823a5761761@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu 22 Apr 2010 at 08:48:55 PDT Rob Farmer wrote:
>On Wed, Apr 21, 2010 at 11:57 PM, Lars Engels <lars.engels@0x20.net> wrote:
>> On Thu, Apr 22, 2010 at 08:18:29AM +0200, Dominic Fandrey wrote:
>>> On 22/04/2010 01:45, Rob Farmer wrote:
>>> > I maintain math/scilab and am preparing to update it. This port has a
>>> > huge plist (slightly under 15000 lines), hundreds of which change
>>> > depending on what options are selected. It is a bit of a pain to
>>> > update. The porters handbook makes vague reference to dynamic plists -
>>> > so I was wondering, would this be a good idea? And if so, what is the
>>> > best way to make one?
>>>
>>> You normally base it on the output of
>>> ${FIND} -s PATH -type f
>>> ${FIND} -d PATH -type d | ${SED} 's,^,@dirrm ,'
>>>
>>> Of course there's normally more to it, but that's the basic principle.
>>>
>>
>> Or use auto-plist:
>> http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi/portstools/auto-plist/
>>
>
>Seems to have the same limitation of genplist - it doesn't address the
>fact that the plist may change if OPTIONS change.
I feel your pain.
But tools like genplist and auto-plist might get you part of the way to
your solution. To get the rest of the way, you might need to write a
custom maintenance script.
Just thinking out loud here, but it seems you'll need to something
similar to what mergemaster does:
- enable all the options and use 'genplist create' to get a new plist
- diff the previous portversion's plist and the new genplist
- emit any lines that haven't changed
- for lines that differ only in the presence of a PLIST_SUB variable at
the beginning of the old line, emit the old line
- ignore any lines which exist only in the old plist
- for lines that are new, prompt for a decision on what to do (leave as
is or preface with one of a predetermined set of PLIST_SUB variables)
This doesn't automate the whole process, but at least it reduces the
manual inspection and intervention to the plist lines that really need
it.
This is only a first stab at the problem, so the steps I outlined
probably need to be refined and debugged.
Or maybe I'm just being stupid. Wouldn't be the first time. :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100422172009.GA27597>