[pacman-dev] Splitting packages in makepkg

[Dan McGee]

On Sat, Jun 14, 2008 at 2:22 PM, Xavier <shiningxc at 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=5e955fc9bd5aa07263179a16b1cebeed9a43d25e
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