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