FS#7982 - patch to makepkg to allow PKGBUILDs building more than one package
Attached to Project:
Pacman
Opened by Johannes Schriewer (dunkelstern) - Sunday, 09 September 2007, 17:10 GMT
Last edited by Dan McGee (toofishes) - Saturday, 17 January 2009, 17:07 GMT
Opened by Johannes Schriewer (dunkelstern) - Sunday, 09 September 2007, 17:10 GMT
Last edited by Dan McGee (toofishes) - Saturday, 17 January 2009, 17:07 GMT
|
Details
Hi there!
I've done a small modification to makepkg to allow for building more than one package from one source tree. It could be used for packages that have one big tar.gz for building multiple applications (like kde has) to split those applications into more than one pacman package. For this to be possible you provide one simple build() function like always and multiple install functions to create the packages then. I introduced a new variable for this named "splitinstall" which lists all install functions. The install functions then simply install the corresponding part of the package and call "pack()" at the end to create the package. All other variables like "pkgrel" and "pkgname" have to be overridden in the install functions to create distinct packages. Of course all "old" PKGBUILDs work as expected. If you don't supply a "splitinstall" entry all is like it was before. I have attached the patch and an example PKGBUILD (kdetoys from KDEmod). Please comment on it. |
makepkg-kdemod-splitpackages....
This task depends upon
Closed by Dan McGee (toofishes)
Saturday, 17 January 2009, 17:07 GMT
Reason for closing: Implemented
Additional comments about closing: See commit 3d49d88009341
Saturday, 17 January 2009, 17:07 GMT
Reason for closing: Implemented
Additional comments about closing: See commit 3d49d88009341
I have attached a PKGBUILD for KDEmod's kdepim which is a little bit more complex, but it also shows the flexibility of this solution. With normal makepkg we had to do a lot of tweaking and deleting in the package itself and not to forget the evil DO_NOT_COMPILE variable. With the patched makepkg we can forget all this and do it in a much cleaner fashion, although the PKGBUILDs get a little bit more crowded :-)
Though, renaming the _install functions to _build would make it clearer. I thought they were related to post_install/pre_install for a second.
Hmm, this is a tough topic as we have free reign to do this here, but want a sane and non-kludgey syntax for it.
Opinions?
Notice that this is for makepkg provided by pacman 3.0.6 as we didnt had the time yet to port it to the new makepkg in pacman 3.1...
Please conside adding this, as we could stop hacking makepkg and have more time providing packages :)
Thanks
Jan
Please review this patch!
new sub-package. We need such a functionality here to split packages for hardening
purposes or to separate things that are not needed by every system...
Is there any chance for an upstream inclusion of that work? I mean this is a really
long standing feature request and i think this should go in sometime.
And can you confirm that the last patch posted here is functional and works fine?
If you want to help its upstream inclusion, review and test it very carefully and improve it if needed.
We use pacman since early 2007 for our in house custom ha-cluster Linux distribution.
We used Makefiles an tar before that point and had no uninstall or dependency tracking...
We got central software distribution with pacman and had a nice an clean migration via
perl-scripts so it was "the richt thing" to adopt pacman for our distribution.
Xavier > And can you confirm that the last patch posted here is functional and works fine?
I can confirm that. To test that we Splittet our php5 package to a base package with
cli api and one for the other APIs (cgi and mod_php). Working well and we spend only
about the half of the build time we used before splitinstall adoption.
(the patch works fine on pacman 3.1.4 also)
Xavier > If you want to help its upstream inclusion, review and test it very carefully and improve it if needed.
I would reorder the saving of the variable-content to the same order as the restore.
I is flexible and simple enough for our use cases as far as i can tell at the moment.
If we encounter any problems along the path to migrate our PKGBUILD files to include
splitinstalls where appropriate, we will contribute patches.
Marc
Well, you could already do something useful, if that is alright with you :
get the above patch from Dimorph, make your reordering cleanup, and submit the new patch to pacman-dev ML inline, so that it can be reviewed there :)
You will need to learn git if you don't know it already, but it will be required for your future patch contribution anyway.
This should help getting you started :
http://code.toofishes.net/git-guide.txt
Otherwise, maybe Dimorph can do that himself.
the splitinstall functions. It should append a comment with the name of
the function started and the logs from it to the logfile of the original
build function. I'll post a patch to the list and here until Sunday.
Marc
0001 is the same patch as above. (git-sha1: 7313c8546ae0a2c38768d665b3f314ee0cf959c4)
0002 have to be applied 0001. This patch fix the logging.
Please review 0002!
Bye DiM
I am currently testing the new patches and they are working properly so far.
You even ported the stuff to latest makepkg, so i really have to say thanks for that, as we havent had the time yet to do that...
Just some remarks from our "daily usage experience" with KDEmod:
- This method of splitting is nice and clean. We can create/update splitted stuff for KDEmod in almost no time (no self-praise, but a result of experience)
- The installation of packages with -i does not work with splitted packages for far, as we didnt needed that and thus it wasnt implemented.
- The split stuff only works if the software provides proper Makefiles. This is not always the case, but i think 99,99% of all software will work just dandy :) (the others need to fix their makefiles :P)
- In the latest KDEmod version of makepkg, we have renamed the splitted PKGBUILDs to "SPLITBUILD", to distinguish them better from the standard ones. What do you think about that? (that was the only change in the last months we did, so i guess you need no patch(es) for that, easy stuff)
As we are currently developing some new automated buildscripts for KDEmod, it would be nice to have the -i option working too. I will try to come up with a patch for that after the weekend, but it could take some time...
Again, many thanks for the initiative guys, you rock!
0001 is the same patch as above. (git-sha1: 7313c8546ae0a2c38768d665b3f314ee0cf959c4)
0002 have to be applied 0001. This patch fix the logging.
Please review 0002!
Bye DiM
DiM
Works, and we have logging :)
Many thanks for that.
Can you bring this up on pacman-dev?
following form which would be cleaner in my opinion.
echo -e "\n\n--- Logging for $it ------------" >> "$BUILDLOG"
When the second patch is just bugfix/improvement of the first one, you just merge both, you don't keep them separated :)
So if you could write a new patch, with the last suggestion from wraiden if you like it,
and post it inline to pacman-dev ML, it would be great.
You should probably have a look at git-send-email for doing that :
http://git.or.cz/gitwiki/GitTips#head-a015948617d9becbdc9836776f96ad244ba87cb8
This is version2 of the patch.
* it builds the packages in different directories
* repackaging works now
To activate this feature you only need a hook-variable "splitinstall" with all
function-names in it.
After performing of build(), it runs all functions in succession.