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
Task Type Feature Request
Category makepkg
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version 3.1.3
Due in Version 4.2.0
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

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
Comment by Travis Willard (Cerebral) - Thursday, 08 May 2008, 20:59 GMT
The general problem with these approaches is that the clarity of the PKGBUILD is potentially muddied by these 'magic' functions.

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)
...
}
Comment by Ray Rashif (schivmeister) - Saturday, 10 May 2008, 10:25 GMT
I once considered posting a similar request, but ultimately decided against it. Ebuilds tend to have functions for a lot of things, including returns and exits (die). Then you have those like dodoc, dobin, dolib, doicon, and similarly in this context - make_desktop_entry (I noticed Allan asking for opinions on this one too in pacman-dev).

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 (:
Comment by Piotr Beling (qwak) - Saturday, 10 May 2008, 11:07 GMT
Hmm... I propose this mechanism to put in libraries functions which makes not banal things (see xpi_install example). I also against making aliases to install!
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.
Comment by Xavier (shining) - Tuesday, 13 May 2008, 20:40 GMT
Just for the record, this was discussed there :
http://archlinux.org/pipermail/pacman-dev/2008-May/011704.html
Comment by Piotr Beling (qwak) - Tuesday, 13 May 2008, 21:29 GMT
There is one problem with: "Required libraries should be placed be package developer in makedepends array."
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).
Comment by Piotr Beling (qwak) - Tuesday, 13 May 2008, 21:42 GMT
... ok, I am rely tired today (must go sleep)... to my last comment:
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"
Comment by Allan McRae (Allan) - Saturday, 17 May 2008, 06:29 GMT
For this to go forward, we would need to generate a list of functions that would be useful to have in a library. There is no point adding this if it will be of limited use.

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.
Comment by Piotr Beling (qwak) - Tuesday, 20 May 2008, 06:37 GMT
For example function for creating entries in /usr/share/gnome-background-properties/ like hare: http://aur.archlinux.org/packages/gnome-backgrounds-qwak/gnome-backgrounds-qwak/PKGBUILD

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)...
Comment by Piotr Beling (qwak) - Tuesday, 20 May 2008, 06:49 GMT
and ttf.install
Comment by Xavier (shining) - Friday, 23 May 2008, 07:28 GMT Comment by Allan McRae (Allan) - Friday, 27 June 2008, 15:53 GMT
See also  FS#1588  for a similar idea.
Comment by Xavier (shining) - Monday, 18 August 2008, 09:03 GMT
A different approach is package file hooks. From TODO.aaron :
<<
* 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 :)
Comment by Muhammed (some-guy94) - Monday, 17 May 2010, 01:31 GMT
Here's a patch implementing a libs system.
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.
Comment by Allan McRae (Allan) - Saturday, 09 February 2013, 05:32 GMT
See here for what is an acceptable solution: https://mailman.archlinux.org/pipermail/pacman-dev/2012-December/016153.html

More work is needed to polish the idea before implementation.

Loading...