Am Montag 16 Juni 2008 17:38:44 schrieb Xavier:
On Sun, Jun 15, 2008 at 3:20 PM, Allan McRae <mcrae_allan@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 the KDEmod team chose option #1. My question is: Was that because it was the best way or was it just because it worked? ...
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 ;)
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Hi there, i just registered at this ML - my first ML experience ever, so please be nice to me :) To answer Allans question about "our way" of building splitted packages... When Dunkelstern and me realized that we cannot maintain over 200 splitted packages with the standard arch makepkg, i sat down and created a first prototype of a PKGBUILD for splitted packages. It was basically the same as what you can see now in our PKGBUILDs, except the splitinstall array - i just created multiple install functions, every one of these with an additional array that holds the directories to "make install" in... Dunkelstern took that idea, added the splitinstall array, created a patch for makepkg, and after some testing and additional patching we had we basically needed... For us, it was (and still is) the best way to create splitted packages without a lot of hassle and/or applying big patches to makepkg (which also have to be maintained, we didnt expect that this will be a topic here) - and this solution works good for us since we created this stuff, and has decreased our workload a lot... About the other 2 solutions Allan wrote about: #2 looks almost the same like our stuff, except that is seems to implement the "base package" stuff statically... We did not want that because with our solution we have no limits and can split stuff like we want... (My english is not that good, maybe i am sounding a bit too generic here)... Its like that: If you already have the possibility to create a "base package", why do you need to create an extra (static) package() function? Our solution already does that by itself, and you can give the install functions any name you want... #3 Seems to move more of the "splitting logic" into the PKGBUILD itself, which isnt so nice imho... Also the case stuff decreases readability in my opinion... With our solution we have just one additional for-loop and an array of the directories to make install in, which is also very clear and readable... So, to come to an end here: I definitely see a some room for improvements regarding our solution, but i also like the flexibility and freedom of it, as you can define nearly everything as you like... And in case you are asking yourself what could be improved: - pkg/ gets deleted after the installation of every sub-package, so re-packaging does not work - the "-i" option to install packages directly after the build does not work with splitted packages (i am currently working on a patch for problem #2) These are the only things that could be improved from my point of view... We are using this stuff since a long time now, and i can say that we are very happy with this solution :) Greetings Jan (funkyou) PS: Again, sorry for my poor english