[pacman-dev] inside PKGBUILD customizable makepkg PURGE_TARGETS

newer
[pacman-dev] [PATCH 1/3] fix a few...

Ciprian Dorin, Craciun

2 Dec 2009 2 Dec '09

5:45 p.m.

Hello all! Again I have a proposal to enhance makepkg PURGE_TARGETS handling. I think that enabling customizing PURGE_TARGETS inside PKGBUILD would be a benefit in the following context: * I have a software package that contains: an application, a static library, a dynamic library, and some development files; * I want to create separate packages: something-bin, something-lib (shared library), something-dev (include and static library), and maybe something-doc; What I have to do today (maybe there is a different way, please correct me): I create a `something-lib_package` function in which I make a normal install, but then I delete all unneeded files. Wouldn't it be better if: a) I was able to define `pkg_purge_targets` also in PKGBUILD, overriding PURGE_TARGETS in makepkg.conf, and, b) allow to have `something-lib_pkg_purge_targets` that allows different purge targets for each "sub-package" overriding those from PKGBUILD or makepkg.conf; Comments? Ideas? Corrections? Thanks, Ciprian. P.S.: If needed I could provide a patch that implements this. P.P.S.: This has nothing to do with my previous proposal about globstar patterns in PURGE_TARGETS.

Show replies by date

Allan McRae

2 Dec 2 Dec

9:48 p.m.

Ciprian Dorin, Craciun wrote:

...

Hello all!

Again I have a proposal to enhance makepkg PURGE_TARGETS handling.

I think that enabling customizing PURGE_TARGETS inside PKGBUILD would be a benefit in the following context:

Without checking, I would have thought that exporting "PURGE_TRAGETS=..." within a package function would just work. I guess the old value would not be restored afterwards though.

...

* I have a software package that contains: an application, a static library, a dynamic library, and some development files; * I want to create separate packages: something-bin, something-lib (shared library), something-dev (include and static library), and maybe something-doc;

What I have to do today (maybe there is a different way, please correct me): I create a `something-lib_package` function in which I make a normal install, but then I delete all unneeded files.

Given this is a fairly common thing to do in the Linux world, most software supports this in the Makefiles. "make install-libs" "make install-docs" etc.

Ciprian Dorin, Craciun

10:17 p.m.

On Wed, Dec 2, 2009 at 11:48 PM, Allan McRae wrote:

...

Ciprian Dorin, Craciun wrote:

...
Hello all!

Again I have a proposal to enhance makepkg PURGE_TARGETS handling.

I think that enabling customizing PURGE_TARGETS inside PKGBUILD would be a benefit in the following context:

Without checking, I would have thought that exporting "PURGE_TRAGETS=..." within a package function would just work. I guess the old value would not be restored afterwards though.

...
* I have a software package that contains: an application, a static library, a dynamic library, and some development files; * I want to create separate packages: something-bin, something-lib (shared library), something-dev (include and static library), and maybe something-doc;

What I have to do today (maybe there is a different way, please correct me): I create a `something-lib_package` function in which I make a normal install, but then I delete all unneeded files.

Given this is a fairly common thing to do in the Linux world, most software supports this in the Makefiles. "make install-libs" "make install-docs" etc.

Unfortunately not all open source software behaves as nice as this... (Actually my experience is on the contrary.) :) As trivia, even pacman doesn't support install-docs, or install-libs target. So a simple solution to this problem, that can be applied as a recipe for most packages, would be: just let the package install as it wants, and then we'll trim off what we don't want. Ciprian.

Dan McGee

3 Dec 3 Dec

12:39 a.m.

On Wed, Dec 2, 2009 at 3:48 PM, Allan McRae wrote:

...

Ciprian Dorin, Craciun wrote:

...
Hello all!

Again I have a proposal to enhance makepkg PURGE_TARGETS handling.

I think that enabling customizing PURGE_TARGETS inside PKGBUILD would be a benefit in the following context:

Without checking, I would have thought that exporting "PURGE_TRAGETS=..." within a package function would just work. I guess the old value would not be restored afterwards though.

This seems like complete overkill for makepkg to support. I'm -1 on this. If upstream builds can't get their act together and provide individual make commands, file a issue upstream. If that doesn't work, then PURGE_TARGETS is really no more than a for file in glob_exp; do rm -f file done which is really just a one-liner in a PKGBUILD anyway. Why complicate the matter? -Dan

Ciprian Dorin, Craciun

4:56 a.m.

On Thu, Dec 3, 2009 at 2:39 AM, Dan McGee wrote:

...

On Wed, Dec 2, 2009 at 3:48 PM, Allan McRae wrote:

...
Ciprian Dorin, Craciun wrote:

...
Hello all!

Again I have a proposal to enhance makepkg PURGE_TARGETS handling.

I think that enabling customizing PURGE_TARGETS inside PKGBUILD would be a benefit in the following context:

Without checking, I would have thought that exporting "PURGE_TRAGETS=..." within a package function would just work. I guess the old value would not be restored afterwards though.

This seems like complete overkill for makepkg to support. I'm -1 on this.

What overkill? Really? It's a 3 or 4-line update: ~~~~ instead of this: if [ "$(check_option purge)" = "y" -a -n "${PURGE_TARGETS[*]}" ]; then msg2 "$(gettext "Purging other files...")" ~~~~ we'll have this: + local purge_targets=( "${pkg_purge_targets[@]:-${PURGE_TARGETS[@]}}" ) + eval 'purge_targets=( "${'"${pkgname}"'_purge_targets[@]:-${purge_targets[@]}" )' + if [ "$(check_option purge)" = "y" -a -n "${purge_targets[*]}" ]; then - if [ "$(check_option purge)" = "y" -a -n "${PURGE_TARGETS[*]}" ]; then msg2 "$(gettext "Purging other files...")" ~~~~ and we have to replace `PURGE_TARGETS` with `purge_targets` somewhare below in 2 places.

...

If upstream builds can't get their act together and provide individual make commands, file a issue upstream. If that doesn't work, then PURGE_TARGETS is really no more than a

Have I mentioned that even pacman doesn't support these make commands?

...

for file in glob_exp; do rm -f file done

which is really just a one-liner in a PKGBUILD anyway. Why complicate the matter?

Actually it's a 3-liner per `something_package` function, in every PKGBUILD, instead of a true 1-liner in every function in every PKGBUILD.

...

-Dan

Guys, as developers of makepkg, you really have something against extensions that would allow writing simpler or more versatile PKGBUILD's... For example, below is one of my PKGBUILDS, that uses what I call a "template", which allows me to abstract away patching, calling configure, and make. And in order to support this split of packages, all I have to do is update my `configure+make+make-install` script to understand this, and just put `pkgname=( isync-bin isync-doc )`. (Unfortunately this doesn't have a lib or dev). My `configure+make+make-install` just implements `build` and `package` functions that use the variables defined in the PKGBUILD, with some sensible defaults. (I think this resembles somehow GoboLinux recipies...) ~~~~ . "${pkgbuild_tools_root}/configure+make+make-install" pkgname=( isync ) _pkgver=1.0.4 _pkgpatch=+1 pkgver="${_pkgver}${_pkgpatch}" pkgrel=1 depends=() makedepends=( openssl db gcc binutils glibc make coreutils bash sed grep patch ) _declare_arch _declare_paths _declare_build_environment _declare_configure_options _configure_options=( "${_configure_options[@]}" --disable-compat ) _LIBS=( "${_LIBS[@]}" -static -ldb -lpthread ) _src_patches=( imap_recursive_maildir.patch imap_certificate_ignore.patch ) source=( "http://switch.dl.sourceforge.net/project/isync/isync/${_pkgver}/isync-${_pkgver}.tar.gz" imap_recursive_maildir.patch imap_certificate_ignore.patch ) md5sums=( 8a836a6f4b43cd38a8b8153048417616 fd42b61f2979d2bf2d08f1528a292ec5 efbe84127425024676b07c2fdef87a98 ) ~~~~ But as I said, no problem, I'll just hack my own makepkg that understands something similar with PKGBUILDS, and extended with these recipies. Thanks, Ciprian.

Allan McRae

5:10 a.m.

Ciprian Dorin, Craciun wrote:

...

On Thu, Dec 3, 2009 at 2:39 AM, Dan McGee wrote:

...
On Wed, Dec 2, 2009 at 3:48 PM, Allan McRae wrote:

...
Ciprian Dorin, Craciun wrote:

...
Hello all!

Again I have a proposal to enhance makepkg PURGE_TARGETS handling.

I think that enabling customizing PURGE_TARGETS inside PKGBUILD would be a benefit in the following context: Without checking, I would have thought that exporting "PURGE_TRAGETS=..." within a package function would just work. I guess the old value would not be restored afterwards though. This seems like complete overkill for makepkg to support. I'm -1 on this.

What overkill? Really? It's a 3 or 4-line update:

~~~~ instead of this: if [ "$(check_option purge)" = "y" -a -n "${PURGE_TARGETS[*]}" ]; then msg2 "$(gettext "Purging other files...")" ~~~~ we'll have this: + local purge_targets=( "${pkg_purge_targets[@]:-${PURGE_TARGETS[@]}}" ) + eval 'purge_targets=( "${'"${pkgname}"'_purge_targets[@]:-${purge_targets[@]}" )' + if [ "$(check_option purge)" = "y" -a -n "${purge_targets[*]}" ]; then - if [ "$(check_option purge)" = "y" -a -n "${PURGE_TARGETS[*]}" ]; then msg2 "$(gettext "Purging other files...")" ~~~~ and we have to replace `PURGE_TARGETS` with `purge_targets` somewhare below in 2 places.

As I said, defining PURGE_TARGETS in a package_foo() function already works: e.g. package_t1() { PURGE_TARGETS=(*.a) touch $pkgdir/foo.a touch $pkgdir/foo.doc } package_t2() { PURGE_TARGETS=(*.doc) touch $pkgdir/foo.a touch $pkgdir/foo.doc } Guess which file ends up in which package...

...

Guys, as developers of makepkg, you really have something against extensions that would allow writing simpler or more versatile PKGBUILD's...

No, we just do not believe any of the ideas you have shown us so far are making simpler PKGBUILDs or achieving something that can not already be done with makepkg using the same number of lines in the PKGBUILD

...

For example, below is one of my PKGBUILDS, that uses what I call a "template", which allows me to abstract away patching, calling configure, and make. And in order to support this split of packages, all I have to do is update my `configure+make+make-install` script to understand this, and just put `pkgname=( isync-bin isync-doc )`. (Unfortunately this doesn't have a lib or dev).

My `configure+make+make-install` just implements `build` and `package` functions that use the variables defined in the PKGBUILD, with some sensible defaults. (I think this resembles somehow GoboLinux recipies...)

~~~~ . "${pkgbuild_tools_root}/configure+make+make-install"

pkgname=( isync ) _pkgver=1.0.4 _pkgpatch=+1 pkgver="${_pkgver}${_pkgpatch}" pkgrel=1

depends=() makedepends=( openssl db gcc binutils glibc make coreutils bash sed grep patch )

_declare_arch _declare_paths _declare_build_environment _declare_configure_options

_configure_options=( "${_configure_options[@]}" --disable-compat )

_LIBS=( "${_LIBS[@]}" -static -ldb -lpthread )

_src_patches=( imap_recursive_maildir.patch imap_certificate_ignore.patch )

source=( "http://switch.dl.sourceforge.net/project/isync/isync/${_pkgver}/isync-${_pkgver}.tar.gz" imap_recursive_maildir.patch imap_certificate_ignore.patch ) md5sums=( 8a836a6f4b43cd38a8b8153048417616 fd42b61f2979d2bf2d08f1528a292ec5 efbe84127425024676b07c2fdef87a98 )

I would not call that simpler. I look at that and have only vague ideas what the packaging would be doing, whereas a normal package I see the exact commands. Allan

5273

Age (days ago)

5274

Last active (days ago)

List overview

Download

5 comments

3 participants

participants (3)

Allan McRae
Ciprian Dorin, Craciun
Dan McGee