[pacman-dev] Splitting packages in makepkg

[Xavier]

On Sun, Jun 15, 2008 at 3:20 PM, Allan McRae <mcrae_allan at hotmail.com> wrote:
> So with a split package, the package part could be:
>
> #1) KDEmod style
>
> package_base() {
>  #do base install
> }
>
> package_gui() {
>  #override pkgname etc
>  # do gui install
> }
>
>
> #2) Modified KDEmod style
>
> package() {
>  # do base install
> }
>
>
> package_gui() {
>  #override pkgname etc
>  # do gui install
> }
>
>
> #3) case statement way
>
> package() {
>  case "$1" in
>    "base" )
>      # do install stuff
>    ;;
>    "gui" )
>      # override pkgname etc
>      # do install stuff
>    ;;
>  esac
> }
>
>
> Now think about how we keep backwards compatibility with old PKGBUILDs
> that don't have a package function of any variety.  Without split
> packages, we have to test if the package() function is present to decide
> whether or not the build() segment is run in fakeroot.  This is
> compatible with splitting methods #2 and #3  where there is a package
> function but not with #1 which would require an additional check for the
> definition of a "split" array. Option #2 also suffers from the problem
> that there may not be a main part to package so it may not be obvious
> what should be in the package() function.  Thus, I think option #2 can
> be excluded from here on.
>
> Option #1 is essentially what the KDEmod team have done and would only
> require an additional test for the "split" array to know what to use
> fakeroot on.  However, you end up with as many package functions as
> there are sub-packages which itself makes the PKGBUILD less clear.
>
> Option #3 is my personal favorite as you still only have two functions -
> build and package.  Admittedly the package function is slightly more
> complex when building a split package but if you wanted it simple, you
> would be using two PKGBUILDs instead of one.  Still, I find it the
> cleaner of the options but I may be fighting a losing campaign here
> given option #1 is "in the wild"...
>
> In the end, I think splitting packages is a nice feature but I doubt I
> will use it frequently.  So the decision should be weighted by those who
> would.  Now the KDEmod team chose option #1.  My question is:  Was that
> because it was the best way or was it just because it worked?  I think
> it would be good to combine the whole split packages, multiple package
> directories, minimal fake install ideas but I am still trying to decide
> what the best way to do this is.
>
>

What bothers me here is that the only question is asked directly to
the kdemod team. I am not sure they all follow this mailing list.
Maybe you should just ask them privately (have a look at the people
who contributed to that bug report).
But personally, I find that option #1 looks nicer ;)