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

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

older
[pacman-dev] Splitting packages in...

Marc - A. Dahlhaus

16 Jun 2008 16 Jun '08

7:49 a.m.

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. + 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. --8<-- thanks, Marc

Show replies by date

Xavier

16 Jun 16 Jun

8:11 a.m.

New subject: [pacman-dev] 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 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.

Silvio Fricke

9:05 a.m.

Hello Friends,

...

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

Me, too!

...

I would prefer having makepkg keeps all split packages in different subdirectories, and have the repackage operation repackage all split packages.

At home, I have it implemented with pkg_$funcname-dirstructure. When I'm at home I will send it to this list. Bye, eS.eF. -- -- S. Fricke ---------------------------------------- silvio@port1024.net -- Diplom-Informatiker (FH) TEL: (+49)8330-911278 Linux-Entwicklung JABBER: silvio@conversation.port1024.net ----------------------------------------------------------------------------

Allan McRae

9:07 a.m.

New subject: [pacman-dev] 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 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

Marc - A. Dahlhaus

10:57 a.m.

New subject: [pacman-dev] 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 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

Allan McRae

2:35 p.m.

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... 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? 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). Allan

Roman Kyrylych

17 Jun 17 Jun

7:28 a.m.

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

2008/6/16 Allan McRae :

...

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 (Роман Кирилич)

Jan Mette

12:07 p.m.

New subject: [pacman-dev] 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

Miklos Vajna

9:30 p.m.

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

On Tue, Jun 17, 2008 at 02:07:37PM +0200, Jan Mette wrote:

...

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

it's your decision but we tried this and it did not work. in fact we just tried to do something like: we had foo-1.0-1 and libfoo-1.0-1 then we had an libfoo-specific problem. so we had libfoo-1.0-2 and foo-1.0-1 then we backported a bugfix from upstream cvs that changed the api, and we had: libfoo-1.0-3 and foo-1.0-2 and then libfoo-1.0-2 was incompatible with foo-1.0-2 there are two workarounds for this: - add proper dependency info this is doable but users will complain about buggy deps and they have reason. this is just illogical - bump foo to 1.0-3 as well. then the question from users will be where is 1.0-2, just like you ask upstream where is 1.0.2 when you see only 1.0.1 and 1.0.3. it's far more easier if you don't mess with different pkgvers/pkgrels for subpackages. of course technically it's doable, just like with pkgdecss, but i would not recommend it.

5803

Age (days ago)

5804

Last active (days ago)

List overview

Download

8 comments

7 participants

participants (7)

Allan McRae
Jan Mette
Marc - A. Dahlhaus
Miklos Vajna
Roman Kyrylych
Silvio Fricke
Xavier