For those who may want to test this, I'm putting more up-to-date patches
in the FTP, which fix several issues found in the one posted yesterday:

	ftp://ftp.NetBSD.org/pub/NetBSD/misc/jmmv/staged.diff

Cheers



On Wed, 7 Apr 2004 15:48:47 +0200
"Julio M. Merino Vidal" <jmmv@menta.net> wrote:

> 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/
> 


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