[pacman-dev] Splitting packages in makepkg

[Xavier]

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.