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. _______________________________________________ pacman-dev mailing list [email protected] http://archlinux.org/mailman/listinfo/pacman-dev
