On Sat, Jun 14, 2008 at 2:22 PM, Xavier <shiningxc@gmail.com> wrote:
Allan McRae wrote:
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 multi function way looks nicer to me.
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.
It seems like we already have a working patch for the kdemod / multifunction way, though it apparently doesn't use separate subdir. So maybe you could try to apply your idea on it?
$pkgdir will already be the recommended way for 3.2 (Dan commented it that way in the man page at least ;) ). With your suggestion, its usage would only be forced in the case of new PKGBUILDs that use the split feature, and not to all existing PKGBUILDs, so I think that's alright.
Yeah, I definitely made those comments in the manpage that way on purpose- this will allow us much greater flexibility in the future, especially for things like building all packages in a tmpfs or something. The only reason I can think you would still want to use a $startdir variable is for something like VCS packages where you store the most recent checkout somewhere for future use. With that said, I've been pretty quiet on this whole split/multiple packages issue simply because I'm not sure what is best, and I'm not the one that would use it. A few thoughts of mine: 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. 2. The above mentioned patch would really play into what worked as far as split packages. I think having the option of one or multiple build functions, followed by multiple install functions, would be beneficial. Here is what I envision, of course I haven't assessed the practicality, and I can already tell I may be thinking too complex after seeing a <30 line patch doing some sort of split. options=('splitpkg') (not sure yet where to stick the names/versions of other sub packages) if build() is present, call build() else if build_pkg1() is present, call that, then build_pkg2(), etc. Each of these would get passed a unique srcdir? call install_pkg1(), install_pkg2(), etc, each with their own unique pkgdir (e.g. don't share a common pkg/ directory). Blah. I don't know. But that patch from item #1 is more important to me than the rest, so keep that in mind when I am looking at any split package patches. -Dan