Why does everybody switch to dynamic plists?

Alexander Leidinger Alexander at Leidinger.net
Sat Jan 22 02:53:27 PST 2005


On Fri, 21 Jan 2005 15:54:16 -0500
Michael Johnson <ahze at ahze.net> wrote:

> >> If the developer of a port puts the dynamic plist generation into a
> >> Makefile target instead of inlining it into the build/install process,
> >> he doesn't needs to put alot more effort into the development process
> >> (just one "make <generate-the-plist-target>") and gets the benefits of
> >> static plists too.
> >>
> this isn't always true. look at www/mozilla or multimedia/vlc. Each have
> thousands of plist files and hundreds that change depending on how the 
> end-user configures the port. It's more reliable to use dynamic plist's
> for these ports. But all in all I like static plist's best.

My initial question was "Why do people _switch_ to dynamic plists even
when a static plist was available?". My general question was triggered
by the commit mail of some java port which exchanged the static plist
with a dynamic one (there may be a valid reason for this port to switch,
but I don't care about it since I want to talk about the global point of
view).

Yes, the extension of the question to all dynamic plists is valid and I
had it in my mind too.

Generally I like to have static plists, but I don't want to have such a
rule be set in stone. If there are valid reason to use a dynamic plist
instead of a static one, we shouldn't use a static one just for the sake
of a potential rule.

For the specific ports you mentioned I partly agree with you.

In the mozilla ports it would be a huge effort (maybe) to get the static
plist right. And since the entire mozilla suite (firefox, mozilla, ...)
seems to be a moving target (to me), we may need to spend such an effort
often. I agree that a dynamic plist makes more sense in this case.

For vlc I think we can come up with a static plist (I haven't looked at
the files which get installed, this is just an "uninformed" judgement
based upon looking at the options the port accepts). Install vlc with
all features enabled, look at the installed files and try to guess which
files belong to which feature. After that you can test the plist in an
automated way (foreach feature install and deinstall the port and look
for stray files and deinstall warnings/errors; in case of a problem
write a log). As long as we expect that the vlc developers don't change
their infrastructure alot, I don't see a reason why this shouldn't work
as expected.

But I don't want to talk about specific ports here. There are valid
reasons to use dynamic plists. I want to generally talk about ports
which use dynamic plists without a valid reason (for those who need
specific examples: the linux ports which get installed out of a binary
RPM don't need a dynamic plist) and about ports which already have a
static plist but get converted to use a dynamic one without the need to
switch.

Bye,
Alexander.

-- 
         The computer revolution is over. The computers won.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7


More information about the freebsd-ports mailing list