Dan McGee wrote:
<snip> 1. I've had this so-called fake_install() branch around for a while locally, and I've always thought it was a decent idea: http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=5e955fc9bd5... The naming of the fake_install() function could change, but what this allows is for the build and install steps of packaging to be seperated, and only the install step gets run under fakeroot. This was the final step towards doing as little work in fakeroot as possible, but I got cold feet on merging it because it would add some possible complexity to PKGBUILDs. However, I think the idea is quite sound and having a build() function and an install() function in a PKGBUILD would not be too much clutter in my opinion.
This looks interesting. And it actually gives me some perspective on which is the best way to implement package splitting. This would make the standard non-split pkgbuild looked like: build() { } package() { } So with a split package, the package part could be: #1) KDEmod style package_base() { #do base install } package_gui() { #override pkgname etc # do gui install } #2) Modified KDEmod style package() { # do base install } package_gui() { #override pkgname etc # do gui install } #3) case statement way package() { case "$1" in "base" ) # do install stuff ;; "gui" ) # override pkgname etc # do install stuff ;; esac } Now think about how we keep backwards compatibility with old PKGBUILDs that don't have a package function of any variety. Without split packages, we have to test if the package() function is present to decide whether or not the build() segment is run in fakeroot. This is compatible with splitting methods #2 and #3 where there is a package function but not with #1 which would require an additional check for the definition of a "split" array. Option #2 also suffers from the problem that there may not be a main part to package so it may not be obvious what should be in the package() function. Thus, I think option #2 can be excluded from here on. Option #1 is essentially what the KDEmod team have done and would only require an additional test for the "split" array to know what to use fakeroot on. However, you end up with as many package functions as there are sub-packages which itself makes the PKGBUILD less clear. Option #3 is my personal favorite as you still only have two functions - build and package. Admittedly the package function is slightly more complex when building a split package but if you wanted it simple, you would be using two PKGBUILDs instead of one. Still, I find it the cleaner of the options but I may be fighting a losing campaign here given option #1 is "in the wild"... In the end, I think splitting packages is a nice feature but I doubt I will use it frequently. So the decision should be weighted by those who would. Now the KDEmod team chose option #1. My question is: Was that because it was the best way or was it just because it worked? I think it would be good to combine the whole split packages, multiple package directories, minimal fake install ideas but I am still trying to decide what the best way to do this is.