[pacman-dev] Splitting packages in makepkg

[Allan McRae]

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=5e955fc9bd5aa07263179a16b1cebeed9a43d25e
> 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.