FS#10375 - support for function libraries for makepkg
Attached to Project:
Pacman
Opened by Piotr Beling (qwak) - Thursday, 08 May 2008, 20:31 GMT
Last edited by Allan McRae (Allan) - Tuesday, 25 June 2013, 05:51 GMT
Opened by Piotr Beling (qwak) - Thursday, 08 May 2008, 20:31 GMT
Last edited by Allan McRae (Allan) - Tuesday, 25 June 2013, 05:51 GMT
|
Details
Some common, not easy to write helper for package developers
(write in bash) functions (to use in install script) should
be available in libraries, like for example in gentoo
portage.
For example see: http://aur.archlinux.org/packages/firefox-adblock-plus/firefox-adblock-plus/PKGBUILD, especially for line: local emid=$(sed -n -e '/<\?em:id>\?/!d; s/.*\([\"{].*[}\"]\).*/\1/; s/\"//g; p; q' install.rdf) || return 1 and compare it to nice xpi_install() function available for all gentoo portage developers in their package build scripts. It is very easy to do this, and it is possible even now by simple include file (library) in PKGBUILD, but some things could be done: All libraries (simple text files with bash functions) could be placed in one (standard) folder. In PKGBUILD variable (for example $mplib) with path to this folder should be available. To use library PKGBUILD should include it by: . $mplib/libname or other (special) syntax (if it possible to do this). Required libraries should be placed be package developer in makedepends array. Makepkg should provide described mechanism and eventually standard library (maybe in future?). Most libraries could be provided other packages. |
This task depends upon
Closed by Allan McRae (Allan)
Tuesday, 25 June 2013, 05:51 GMT
Reason for closing: Implemented
Additional comments about closing: git commit ce312519 and following
Tuesday, 25 June 2013, 05:51 GMT
Reason for closing: Implemented
Additional comments about closing: git commit ce312519 and following
That said, I like this proposal in that everything is explicit - if you want to use the special library, you have to specifically source it. One would hope that the people would comment the line too, so that in the PKGBUILD you'd see
# Needed for xpi_install()
source $libdir/xpi
build ()
{
...
xpi_install(args)
...
}
Sure, they're easy - and can be simple - in a sense. For example, the desktop entry function could take just the more important arguements: exec, name, icon, category. For installing binaries and libraries, it could be as simple as an alias for `install`.
If we were to implement something like that, then the so-called simplicity of a PKGBUILD would no longer be valid. I do wonder, however, if by writing functions inside the buildscript itself, we are going against that simplicity? If that's the case, then by all means, I vote for this one (:
I thing that proposed mechanism is much better than for example making copy of xpi_install function in each PKGBUILD with firefox extension.
Idea is good but in gentoo it is misuse.
http://archlinux.org/pipermail/pacman-dev/2008-May/011704.html
Because if library not exist in filesystem "source $libdir/notexistinglib" cause error in "source PKGBUILD" (I thing that makepkg do something like this).
The solution (proposal 1):
in $libdir will be placed libraries category files (distributed with makepkg), for example: desktop, xpi, etc...
Each of this file will do something like this: source $libdir/impl/categoryname/* (if $libdir/impl/categoryname/ is not empty)
Libraries will be placed in $libdir/impl/categoryname/ (in proper category dir)
PKGBUILD should include category file: source $libdir/categoryname ($libdir/categoryname exists so everything is ok)
makepkg check makedepends and never call install() if any library missing
The solution (proposal 2) (much worse in my opinion):
Libraries will be only standard and provided only with makepkg (not by other packages).
Solution is of course trivial: makepkg should provide function (for example: function include {...}) to includes libraries files witch should check if library exist and include it only if exist.
PKGBUILD now could safely: "include libname" instead of "source $libdir/libname"
Suggestions so far:
create_desktop_file()
xpi_intstall()
What other functions would people like? Two functions is not worth the time this would take. If people suggest enough ideas to make this worth while, I will look into implementing a proof of principle patch.
In $libdir could be also install directory with ready to attach common used install scripts, for example:
font.install (updating font cache), texlive.install (with texconfig-sys rehash), tetex.install (mktexlsr) (maybe last 2 files should be in one tex.install, calling which is needed depend on installed tex distro)...
FS#1588for a similar idea.<<
* feature for 3.1: package file hooks *
I've been planning on this one for some time. Here's a simple rundown:
in /etc/pacman.d/hooks:
Hook /usr/include/* : /usr/bin/ctags -R /usr/include/*.h -f /usr/include/systags
This will allow us to make "global hooks" to simplify a lot of repetitive
install files (scrollkeeper, depmod, etc). This also allows us to move
ldconfig out of pacman entirely.
possible: /etc/pacman.hooks/* files for hooks, so packages can add them too
>>
Of course this was not in 3.1 and is not in 3.2 either :)
A PKGBUILD (or lib) can add a line libs=(somelib), and that will be loaded by makepkg.
I haven't fully tested this, but it should work fine.
More work is needed to polish the idea before implementation.