Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   ArchLinux Pacman Development (http://www.linux-archive.org/archlinux-pacman-development/)
-   -   FS#7982 - patch to makepkg to allow PKGBUILDs building more than one package (http://www.linux-archive.org/archlinux-pacman-development/107592-fs-7982-patch-makepkg-allow-pkgbuilds-building-more-than-one-package.html)

Xavier 06-16-2008 08:11 AM

FS#7982 - patch to makepkg to allow PKGBUILDs building more than one package
 
On Mon, Jun 16, 2008 at 9:49 AM, Marc - A. Dahlhaus <mad@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.

> + 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.
>

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.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Allan McRae 06-16-2008 09:07 AM

FS#7982 - patch to makepkg to allow PKGBUILDs building more than one package
 
Xavier wrote:
> On Mon, Jun 16, 2008 at 9:49 AM, Marc - A. Dahlhaus <mad@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.

>
>> + 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.

> 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



_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

"Marc - A. Dahlhaus" 06-16-2008 10:57 AM

FS#7982 - patch to makepkg to allow PKGBUILDs building more than one package
 
Allan McRae schrieb:
> Xavier wrote:
>
>> On Mon, Jun 16, 2008 at 9:49 AM, Marc - A. Dahlhaus <mad@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

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

"Roman Kyrylych" 06-17-2008 07:28 AM

FS#7982 - patch to makepkg to allow PKGBUILDs building more than one package
 
2008/6/16 Allan McRae <mcrae_allan@hotmail.com>:
>
> Why would we need to change license, pkgver and url? This is for
> splitting packages that come in a single source file... Otherwise you
> make two PKGBUILDs. Can anyone give me a possible reason for changing
> these.

IIRC once I maintained a package (a game) that had its data under a
different license than source,
but was packaged in one tarball (my memory may be wrong though).

> I really think we need to take a big step back here. What we really
> need is to have a prototype PKGBUILD for a split package that is
> relatively agreed upon. As I said in other emails there are multiple
> ways to do this and one needs to be chosen. Once the decisions have
> been made about the approach to take, and a naming scheme for
> functions/variables, then we can look at patches. At the moment the
> patches seem without a defined goal (at least to me).

agree

--
Roman Kyrylych (*оман Кирилич)
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Jan Mette 06-17-2008 12:07 PM

FS#7982 - patch to makepkg to allow PKGBUILDs building more than one package
 
Am Montag 16 Juni 2008 16:35:33 schrieb Allan McRae:
> I have been thinking about this some more and my head is beginning to
> hurt...
>
> > + 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
>
> Why would we need to change license, pkgver and url? This is for
> splitting packages that come in a single source file...

Just one example: GTK-KDE4 (check kde-look.org) consists of two tarballs
on different sources, with different licences... (The gtk part is GPL, the qt4
part seems to have no proper license yet)...

However, we dont split this package (yet), i just wanted to come up with an
example.

> Otherwise you
> make two PKGBUILDs. Can anyone give me a possible reason for changing
> these. I'm not sure about groups but there might be some reason to
> change that. I can think of reasons to change the options array so that
> should be included. Should we allow varying pkgrels between the split
> packages?

Another example: Our kdebase-workspace package is split into 3 pkgs:
kdebase-workspace (binaries), kdebase-workspace-docs and
kdebase-workspace-icons... When we rebuild this package, we just bump
the kdebase-workspace pkg, but not the two with docs and icons... So, for
us, there is definitely a need to vary pkgrels between the split pkgs...

> I really think we need to take a big step back here. What we really
> need is to have a prototype PKGBUILD for a split package that is
> relatively agreed upon. As I said in other emails there are multiple
> ways to do this and one needs to be chosen. Once the decisions have
> been made about the approach to take, and a naming scheme for
> functions/variables, then we can look at patches. At the moment the
> patches seem without a defined goal (at least to me).

Check this one as a "real world" prototype:

http://www.kdemod.ath.cx/svn/branches/kde41/kdetoys/SPLITBUILD

(Ignore the SPLITBUILD stuff, just a small change to distiguish them better)


Greetings

Jan



_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev


All times are GMT. The time now is 10:16 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.