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