[pacman-dev] Splitting packages in makepkg

[Allan McRae]

NOTE: This is a discussion about the technical implementation of the 
ability to build split packages in makepkg.  DO NOT reply if all you 
want to say is splitting packages is a bad thing.  Just because makepkg 
can split packages does not mean Arch will start splitting everything up 
into binary/header packages.  I can say with great certainty that that 
will never happen.


I was going to wait until 3.2 was out the door to start implementing the 
ability to split packages but there has been enough activity on the bug 
tracker lately that I thought this discussion would be timely.

There have been several proposals for building split packages with 
makepkg. See:
http://bugs.archlinux.org/task/7144
http://bugs.archlinux.org/task/7982
http://bugs.archlinux.org/task/8187

The question is how best to implement this.  I can not see any other way 
than having a "split" array listing the names of the split components, 
so the need for this is almost a given.

With input from the bug reports, I see two possible ways to implement 
this (in the PKGBUILD):

1) The KDEMod style (FS#7982), where each package has its own install 
function. e.g.

base_install() {
    # do install stuff
}

gui_install() {
    # override pkgname etc
    # do install stuff
}


2) A "package" function with a case statement. e.g.

package() {
  case "$1" in
    "base" )
      # do install stuff    
    ;;        
    "gui" )
    # override pkgname etc
    # do install stuff        
    ;;
  esac
}

I am kind of torn here...  I like the idea of having a single function 
but the syntax is slightly more complex.  Although the multi function 
version is already in use, that should not be a limiting factor - we 
should be striving for technical elegance rather than accepting the 
current situation.  


The second point I would like to bring up is based on the suggestion in 
FS#8187.  In it I suggested  having separate subdirectories where each 
sub-package is installed into.  This would be a benefit because it would 
not require the clearing of the pkg directory after each sub-package 
install as in the current KDEmod implementation.  I see this would be a 
definite help when bugfixing a PKGBUILD as you can easily browse the 
installed files.  It would also mean that we could keep the repackage 
option working.

This could be implemented with either method by setting the pkgdir 
variable before calling whichever package function is chosen.  But it 
would require the forcing of the use of $pkgdir rather than 
$startdir/pkg as that would fail. 


So people, what are you opinions on the ideas above?  These are just the 
choices I can currently see so don't feel limited to only commenting on 
them.  At this stage I would not worry about the actual naming scheme of 
functions etc, just the implementation.  So please discuss (after going 
back and reading the top paragraph...).

Allan