Hi all,

while testing pkgsrc under Linux, I hit some PLIST problems because some
packages install different files depending on the build system.  This is
a common situation that has been found by many other people in the past,
and for which we have ugly PLIST hacks to workaround it (see libgtop2,
gnome2-applets, icu, for example).  And I'm sure there are lots of
problems like this remaining in our tree, which can only be fixed by
trying packages and/or looking at bulk build results; eww.

I wonder why we insist on keeping static PLISTs, where almost all other
packaging systems out there use dynamic ones (e.g., Gentoo's portage,
Debian packages, RPMs... and yes, even pkgviews).

Having them could make maintenance a lot easier, specially when it comes
to portability.  No more PLIST hacks, no more need to handle shared
directories with ugly ${RMDIR} lines, no more need for *-dirs packages...
And also, lots of free inodes! ;)

OTOH, with static PLISTs, one can easily grep for files, but this can be
worked around by generating file lists when doing bulk builds (a thing we
do very often).  Think for example about DEBs; you can search individual
files from the Debian's website...

Yes, doing dynamic PLISTs mean staged installs as a prerequisite, and
this is what, IIRC, everybody says is difficult.  Almost all packages out
there support it with no problems, specially if they use automake, as the
DESTDIR feature is provided by it.  Also, considering that other packaging
systems use this feature, one can assume that they ask authors to fix
their packages to support it (I, for one, got some messages about this for
my own programs, when RPM packages were created for them by a third party).

And, for those packages that don't support staged installs... well, we
could either fix them (which could require many patches), or continue to
use static PLISTs (which could mean that the staged install is disabled
for that specific package).  I don't see any problem in keeping them for
packages that can't be easily converted.

Am I missing the real reason for why we don't do this?  If not, and people
agrees, could we do it?  (We could simply add support for staged installs
and dynamic lists, but keep the default behavior as is now.  Then, start
converting packages one by one, when needed/wanted.)

Thanks.

-- 
Julio M. Merino Vidal <jmmv@menta.net>
The NetBSD Project - http://www.NetBSD.org/