[pacman-dev] FS#7982 - patch to makepkg to allow PKGBUILDs building more than one package

[Marc - A. Dahlhaus]

Allan McRae schrieb:
> Xavier wrote:
>   
>> On Mon, Jun 16, 2008 at 9:49 AM, Marc - A. Dahlhaus <mad at wol.de> wrote:
>>   
>>     
>>> Hello List,
>>>
>>> a few comments on the posted patch...
>>>
>>> @@ -1389,7 +1391,57 @@ if [ "$INFAKEROOT" = "1" ]; then
>>>                tidy_install
>>>        fi
>>>
>>> -       create_package
>>> +       if [ "$splitinstall" != "" ] ; then
>>> +               backup_o=$backup
>>> +               conflicts_o=$conflicts
>>> +               depends_o=$depends
>>> +               groups_o=$groups
>>> +               install_o=$install
>>> +               license_o=$license
>>> +               pkgdesc_o=$pkgdesc
>>> +               pkgname_o=$pkgname
>>> +               pkgver_o=$pkgver
>>> +               provides_o=$provides
>>> +               replaces_o=$replaces
>>> +               url_o=$url
>>>
>>> This is the right place to do this in my opinion, that way you have the global defined defaults for every slpit-package.
>>> To move this inside of the loop would kill the posibility to get the fuits from my next comment.
>>>
>>>     
>>>       
>> That is not how I understood Allan's comment.
>> I understood he was suggesting to transform this long enumeration to a loop.
>>   
>>     
>
> The loop is what I was after.
>   
Ok, i've misinterpreted it.
>   
>>   
>>     
>>> +               create_package
>>>
>>> I think this is wrong from the view to build sub-packages out of one compiled tree.
>>> build should be used to only build the sources and prepare everything which would be usefull for all subpackages.
>>>
>>> That way we could add a new param to makepkg to bould only a subset of the splitpackages by overriding the contents of the defined var splitinstall.
>>>
>>>
>>> +               for it in "${splitinstall[@]}" ; do
>>> +                       if [ -d "$pkgdir" ]; then
>>> +                               msg "Removing existing pkg/ directory..."
>>> +                               rm -rf "$pkgdir"
>>> +                       fi
>>> +                       mkdir -p "$pkgdir"
>>>
>>> I like it that way and we can fix the issue spotted by *Allan McRae* (non working repackage param) if we take the way of my prevous comment and allow to rebuild only a subset of the splitpackages.
>>> I think we should add the splitpackage-name to repackage as additional param to makepkg's command line and use that to override the splitinstall value in case we want repackage.
>>>
>>>     
>>>       
>>   
>>     
>
> Repackaging does no building at all, it just zips up the pkg directory 
> with the necessary files.  So allowing a splitpkg parameter for the 
> repackage option would not work with the current implementation.
>   
Yes of course, a repackage should not rebuild anything.
The suggested separation of building (function build) from installation 
(a function in splitinstall array) would achieve that for you.
The repackaging would just overwrite the data (by installing it) and the 
vars for your package (pkgname, deps...) and repackage it.
The normal workflow after an error would be to fix it inside of your 
PKGBUILD file instead of in the pkg directory anyway.
Also it wouldn't work without altering the variables to get 
splitpackages out in a repackaging case the way you would in a normal 
build without running the install function which alters the pkgbuild 
vars for you.

Some nice cornercases would be that you could list all dependencies you 
need to build all of your subpackages in your main definition on top of 
your PKGBUILD.
And you can break down to the ones really needed for a splitpackage in 
your install function.
Think about a package php-common and splitpackage php-mysql in case of 
the dependencies to (lib)mysql...
>> That looks quite weird to me.
>> I would prefer having makepkg keeps all split packages in different
>> subdirectories, and have the repackage operation repackage all split
>> packages.
>>   
>>     
>
> Agreed that is the way to fix this...
>
> Allan

The point of this suggestion was to make it possible to reuse allready 
working and tested code as much as possible.
But it was just a proposal from my point of view at that time.
After some thinking i came to the conclusion that it would be better to 
have all splitinstall trees around after a run without "-c" to check if 
the dependencies are correct.
So let's do it that way.


Marc