[pacman-dev] [PATCH] Introduce destarch keyword into makepkg
If destarch is added to a PKGBUILD, makepkg sets the architecture of the resulting package to $destarch instead of $CARCH. This is useful if you want to cross-create packages for one architecture on the other. Using arch=('i686') destarch='x86_64' makes it possible to build multilib packages and to build grub without the export CARCH="x86_64" hack. --- scripts/makepkg.sh.in | 32 ++++++++++++++++++-------------- 1 files changed, 18 insertions(+), 14 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index bce2e6c..c45d7e8 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -152,7 +152,7 @@ clean_up() { rm -rf pkg src if [ "$pkgname" != "" ]; then # Can't do this unless the BUILDSCRIPT has been sourced. - rm -f "${pkgname}-${pkgver}-${pkgrel}-${CARCH}.log*" + rm -f "${pkgname}-${pkgver}-${pkgrel}-${destarch}.log*" fi fi @@ -662,7 +662,7 @@ run_build() { local ret=0 if [ "$LOGGING" = "1" ]; then - BUILDLOG="${startdir}/${pkgname}-${pkgver}-${pkgrel}-${CARCH}.log" + BUILDLOG="${startdir}/${pkgname}-${pkgver}-${pkgrel}-${destarch}.log" if [ -f "$BUILDLOG" ]; then local i=1 while true; do @@ -792,8 +792,8 @@ create_package() { echo "builddate = $builddate" >>.PKGINFO echo "packager = $packager" >>.PKGINFO echo "size = $size" >>.PKGINFO - if [ "$CARCH" != "" ]; then - echo "arch = $CARCH" >>.PKGINFO + if [ "$destarch" != "" ]; then + echo "arch = $destarch" >>.PKGINFO fi if [ "$(check_option force)" = "y" ]; then echo "force = true" >> .PKGINFO @@ -851,7 +851,7 @@ create_package() { # tar it up msg2 "$(gettext "Compressing package...")" - local pkg_file="$PKGDEST/${pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT}" + local pkg_file="$PKGDEST/${pkgname}-${pkgver}-${pkgrel}-${destarch}${PKGEXT}" if ! bsdtar -czf "$pkg_file" $comp_files *; then error "$(gettext "Failed to create package file.")" @@ -872,11 +872,11 @@ create_xdelta() { local pkginfo="$(mktemp "$startdir"/xdelta-pkginfo.XXXXXXXXX)" local old_file old_version - for old_file in $(ls {"$cache_dir","$PKGDEST"}/${pkgname}-*-*{,-$CARCH}$PKGEXT 2>/dev/null); do + for old_file in $(ls {"$cache_dir","$PKGDEST"}/${pkgname}-*-*{,-$destarch}$PKGEXT 2>/dev/null); do bsdtar -xOf "$old_file" .PKGINFO > "$pkginfo" || continue if [ "$(cat "$pkginfo" | grep '^pkgname = ')" != "pkgname = $pkgname" ]; then continue # Package name does not match. - elif [ "$(cat "$pkginfo" | grep '^arch = ')" != "arch = $CARCH" ] ; then + elif [ "$(cat "$pkginfo" | grep '^arch = ')" != "arch = $destarch" ] ; then continue # Not same arch. fi @@ -894,7 +894,7 @@ create_xdelta() { if [ "$base_file" != "" ]; then msg "$(gettext "Making delta from version %s...")" "$latest_version" - local delta_file="$PKGDEST/$pkgname-${latest_version}_to_$pkgver-$pkgrel-$CARCH.delta" + local delta_file="$PKGDEST/$pkgname-${latest_version}_to_$pkgver-$pkgrel-$destarch.delta" local ret=0 # xdelta will decompress base_file & pkg_file into TMP_DIR (or /tmp if @@ -984,9 +984,9 @@ install_package() { [ "$INSTALL" = "0" ] && return msg "$(gettext "Installing package ${pkgname} with pacman -U...")" if [ "$ASROOT" = "0" ]; then - sudo pacman $PACMAN_OPTS -U $PKGDEST/${pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT} || exit $? + sudo pacman $PACMAN_OPTS -U $PKGDEST/${pkgname}-${pkgver}-${pkgrel}-${destarch}${PKGEXT} || exit $? else - pacman $PACMAN_OPTS -U $PKGDEST/${pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT} || exit $? + pacman $PACMAN_OPTS -U $PKGDEST/${pkgname}-${pkgver}-${pkgrel}-${destarch}${PKGEXT} || exit $? fi } @@ -1330,6 +1330,10 @@ if [ "$arch" = 'any' ]; then CARCH='any' fi +if [ -z "$destarch" ]; then + destarch="$CARCH" +fi + if ! in_array $CARCH ${arch[@]}; then if [ "$IGNOREARCH" = "0" ]; then error "$(gettext "%s is not available for the '%s' architecture.")" "$pkgname" "$CARCH" @@ -1374,7 +1378,7 @@ unset valid_options opt known kopt devel_check devel_update -if [ -f "$PKGDEST/${pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT}" \ +if [ -f "$PKGDEST/${pkgname}-${pkgver}-${pkgrel}-${destarch}${PKGEXT}" \ -a "$FORCE" = "0" -a "$SOURCEONLY" = "0" -a "$NOBUILD" = "0" ]; then if [ "$INSTALL" = "1" ]; then warning "$(gettext "A package has already been built, installing existing package...")" @@ -1402,7 +1406,7 @@ if [ "$INFAKEROOT" = "1" ]; then exit 0 # $E_OK fi -msg "$(gettext "Making package: %s")" "$pkgname $pkgver-$pkgrel $CARCH ($(date))" +msg "$(gettext "Making package: %s")" "$pkgname $pkgver-$pkgrel $destarch ($(date))" if [ $EUID -eq 0 ]; then warning "$(gettext "Running makepkg as root...")" @@ -1504,10 +1508,10 @@ else fi fi - create_xdelta "$PKGDEST/${pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT}" + create_xdelta "$PKGDEST/${pkgname}-${pkgver}-${pkgrel}-${destarch}${PKGEXT}" fi -msg "$(gettext "Finished making: %s")" "$pkgname $pkgver-$pkgrel $CARCH ($(date))" +msg "$(gettext "Finished making: %s")" "$pkgname $pkgver-$pkgrel $destarch ($(date))" install_package -- 1.5.6
When a package A requires a package B at runtime, but B is not needed for building A or B cannot be installed while A is being built, rundepends=('B') can be used to add B to A's dependencies, omitting the dependency check at built time. --- scripts/makepkg.sh.in | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index c45d7e8..c809498 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -809,7 +809,7 @@ create_package() { for it in "${groups[@]}"; do echo "group = $it" >>.PKGINFO done - for it in "${depends[@]}"; do + for it in "${depends[@]} ${rundepends[@]}"; do echo "depend = $it" >>.PKGINFO done for it in "${optdepends[@]}"; do @@ -1287,7 +1287,7 @@ fi unset pkgname pkgver pkgrel pkgdesc url license groups provides md5sums unset replaces depends conflicts backup source install build makedepends -unset optdepends options noextract +unset optdepends options noextract rundepends if [ ! -f "$BUILDSCRIPT" ]; then error "$(gettext "%s does not exist.")" "$BUILDSCRIPT" -- 1.5.6
This patch introduces a new STRIP_DIRS makepkg.conf option to change makepkg's search path when stripping binaries. --- etc/makepkg.conf.in | 2 ++ scripts/makepkg.sh.in | 8 +++++--- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/etc/makepkg.conf.in b/etc/makepkg.conf.in index bb2018f..75dd0e9 100644 --- a/etc/makepkg.conf.in +++ b/etc/makepkg.conf.in @@ -73,6 +73,8 @@ OPTIONS=(strip docs libtool emptydirs zipman) INTEGRITY_CHECK=(md5) #-- Info and doc directories to remove (if option set correctly above) DOC_DIRS=(usr/{,share/}{info,doc,gtk-doc} opt/*/{info,doc,gtk-doc}) +#-- Directories to be searched for the strip option +STRIP_DIRS=(bin lib sbin usr/{bin,lib,sbin,local/{bin,lib,sbin}} opt/*/{bin,lib,sbin}) ######################################################################### # PACKAGE OUTPUT diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index c809498..4a6f9b2 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -737,9 +737,11 @@ tidy_install() { if [ "$(check_option strip)" = "y" ]; then msg2 "$(gettext "Stripping debugging symbols from binaries and libraries...")" - local binary bindirs - bindirs="bin lib sbin usr/bin usr/lib usr/sbin usr/local/bin usr/local/lib usr/local/sbin opt/*/bin opt/*/lib opt/*/sbin" - find ${bindirs} -type f 2>/dev/null | while read binary ; do + local binary + if [ -z "${STRIP_DIRS[@]}" ]; then + STRIP_DIRS=(bin lib sbin usr/{bin,lib,sbin,local/{bin,lib,sbin}} opt/*/{bin,lib,sbin}) + fi + find ${STRIP_DIRS[@]} -type f 2>/dev/null | while read binary ; do case "$(file -biz "$binary")" in *application/x-sharedlib*) # Libraries /usr/bin/strip --strip-debug "$binary";; -- 1.5.6
On Tue, Jul 1, 2008 at 12:47 PM, Thomas Bächler <thomas@archlinux.org> wrote:
This patch introduces a new STRIP_DIRS makepkg.conf option to change makepkg's search path when stripping binaries. --- etc/makepkg.conf.in | 2 ++ scripts/makepkg.sh.in | 8 +++++--- 2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/etc/makepkg.conf.in b/etc/makepkg.conf.in index bb2018f..75dd0e9 100644 --- a/etc/makepkg.conf.in +++ b/etc/makepkg.conf.in @@ -73,6 +73,8 @@ OPTIONS=(strip docs libtool emptydirs zipman) INTEGRITY_CHECK=(md5) #-- Info and doc directories to remove (if option set correctly above) DOC_DIRS=(usr/{,share/}{info,doc,gtk-doc} opt/*/{info,doc,gtk-doc}) +#-- Directories to be searched for the strip option +STRIP_DIRS=(bin lib sbin usr/{bin,lib,sbin,local/{bin,lib,sbin}} opt/*/{bin,lib,sbin})
######################################################################### # PACKAGE OUTPUT diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index c809498..4a6f9b2 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -737,9 +737,11 @@ tidy_install() {
if [ "$(check_option strip)" = "y" ]; then msg2 "$(gettext "Stripping debugging symbols from binaries and libraries...")" - local binary bindirs - bindirs="bin lib sbin usr/bin usr/lib usr/sbin usr/local/bin usr/local/lib usr/local/sbin opt/*/bin opt/*/lib opt/*/sbin" - find ${bindirs} -type f 2>/dev/null | while read binary ; do + local binary + if [ -z "${STRIP_DIRS[@]}" ]; then + STRIP_DIRS=(bin lib sbin usr/{bin,lib,sbin,local/{bin,lib,sbin}} opt/*/{bin,lib,sbin}) + fi + find ${STRIP_DIRS[@]} -type f 2>/dev/null | while read binary ; do This breaks what was fixed here; you'll need to resubmit with that in mind: http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=27943a04d6dd13562...
case "$(file -biz "$binary")" in *application/x-sharedlib*) # Libraries /usr/bin/strip --strip-debug "$binary";; --
Otherwise I think it makes sense, anyone object? -Dan
Dan McGee schrieb:
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index c809498..4a6f9b2 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -737,9 +737,11 @@ tidy_install() {
if [ "$(check_option strip)" = "y" ]; then msg2 "$(gettext "Stripping debugging symbols from binaries and libraries...")" - local binary bindirs - bindirs="bin lib sbin usr/bin usr/lib usr/sbin usr/local/bin usr/local/lib usr/local/sbin opt/*/bin opt/*/lib opt/*/sbin" - find ${bindirs} -type f 2>/dev/null | while read binary ; do + local binary + if [ -z "${STRIP_DIRS[@]}" ]; then + STRIP_DIRS=(bin lib sbin usr/{bin,lib,sbin,local/{bin,lib,sbin}} opt/*/{bin,lib,sbin}) + fi + find ${STRIP_DIRS[@]} -type f 2>/dev/null | while read binary ; do This breaks what was fixed here; you'll need to resubmit with that in mind: http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=27943a04d6dd13562...
I don't understand what you mean. The "find" line is unchanged. Can you elaborate?
On Tue, Jul 1, 2008 at 2:27 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Dan McGee schrieb:
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index c809498..4a6f9b2 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -737,9 +737,11 @@ tidy_install() {
if [ "$(check_option strip)" = "y" ]; then msg2 "$(gettext "Stripping debugging symbols from binaries and libraries...")" - local binary bindirs - bindirs="bin lib sbin usr/bin usr/lib usr/sbin usr/local/bin usr/local/lib usr/local/sbin opt/*/bin opt/*/lib opt/*/sbin" - find ${bindirs} -type f 2>/dev/null | while read binary ; do + local binary + if [ -z "${STRIP_DIRS[@]}" ]; then + STRIP_DIRS=(bin lib sbin usr/{bin,lib,sbin,local/{bin,lib,sbin}} opt/*/{bin,lib,sbin}) + fi + find ${STRIP_DIRS[@]} -type f 2>/dev/null | while read binary ; do
This breaks what was fixed here; you'll need to resubmit with that in mind:
http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=27943a04d6dd13562...
The bash {} expansion was causing some problems I believe, otherwise I'm not completely sure why I would have changed that. The referenced patch definitely made that change, I wish I would have documented better why... -Dan
Dan McGee schrieb:
This breaks what was fixed here; you'll need to resubmit with that in mind:
http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=27943a04d6dd13562...
The bash {} expansion was causing some problems I believe, otherwise I'm not completely sure why I would have changed that. The referenced patch definitely made that change, I wish I would have documented better why...
I thought the problem was 'for i in $(find ....)' vs. 'find .... | while read line'. find will display one file per line. The 'for' loop will iterate over the words, not the lines, thus whitespace in filenames will break. The 'read' will always read a line and treat it as one word, ignoring whitespace. The bash expansion on the find commandline will quote everything properly, so the find command will have all the paths. Thus, I think the patch is correct.
Thomas Bächler wrote:
This patch introduces a new STRIP_DIRS makepkg.conf option to change makepkg's search path when stripping binaries.
Again, I am happy for this to be included once documentation has been added (makepkg.conf.5.txt). Allan
On Tue, Jul 1, 2008 at 12:47 PM, Thomas Bächler <thomas@archlinux.org> wrote:
When a package A requires a package B at runtime, but B is not needed for building A or B cannot be installed while A is being built, rundepends=('B') can be used to add B to A's dependencies, omitting the dependency check at built time. --- scripts/makepkg.sh.in | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index c45d7e8..c809498 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -809,7 +809,7 @@ create_package() { for it in "${groups[@]}"; do echo "group = $it" >>.PKGINFO done - for it in "${depends[@]}"; do + for it in "${depends[@]} ${rundepends[@]}"; do echo "depend = $it" >>.PKGINFO done for it in "${optdepends[@]}"; do @@ -1287,7 +1287,7 @@ fi
unset pkgname pkgver pkgrel pkgdesc url license groups provides md5sums unset replaces depends conflicts backup source install build makedepends -unset optdepends options noextract +unset optdepends options noextract rundepends
if [ ! -f "$BUILDSCRIPT" ]; then error "$(gettext "%s does not exist.")" "$BUILDSCRIPT" --
I've been contemplating something like this for a while as well. What do others on the list think, is this getting to be too much, or does this make sense? I think I would be fine with it. We will need documentation (namely PKGBUILD.5.txt) to be patched as well in the final patch. -Dan
On Tue, Jul 01, 2008 at 01:11:11PM -0500, Dan McGee <dpmcgee@gmail.com> wrote:
I've been contemplating something like this for a while as well. What do others on the list think, is this getting to be too much, or does this make sense? I think I would be fine with it. We will need documentation (namely PKGBUILD.5.txt) to be patched as well in the final patch.
http://bugs.archlinux.org/task/2891 Aaron closed this as "Wont't implement" two years ago.
Miklos Vajna schrieb:
I've been contemplating something like this for a while as well. What do others on the list think, is this getting to be too much, or does this make sense? I think I would be fine with it. We will need documentation (namely PKGBUILD.5.txt) to be patched as well in the final patch.
Didn't think of that.
http://bugs.archlinux.org/task/2891
Aaron closed this as "Wont't implement" two years ago.
It is a good feature for a packager. I am doing some packages where I always have to build with -d, as some of the dependencies are never present at build time. However, I still want makepkg to check whether all other dependencies are there.
On Tue, Jul 1, 2008 at 2:32 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Miklos Vajna schrieb:
I've been contemplating something like this for a while as well. What do others on the list think, is this getting to be too much, or does this make sense? I think I would be fine with it. We will need documentation (namely PKGBUILD.5.txt) to be patched as well in the final patch.
Didn't think of that.
http://bugs.archlinux.org/task/2891
Aaron closed this as "Wont't implement" two years ago.
My name isn't Aaron, now is it?
It is a good feature for a packager. I am doing some packages where I always have to build with -d, as some of the dependencies are never present at build time. However, I still want makepkg to check whether all other dependencies are there.
I do see the use in this because I build regularly where I need to use the -d option, which unfortunately prevents a single dependency from being checked. Two years is a long time, so there has been plenty of time to reconsider, and I find the reasons in the bug report just as valid as they were two years ago. -Dan
On Tue, Jul 01, 2008 at 02:42:15PM -0500, Dan McGee <dpmcgee@gmail.com> wrote:
http://bugs.archlinux.org/task/2891
Aaron closed this as "Wont't implement" two years ago.
My name isn't Aaron, now is it?
OK, it was just a FYI. :-)
Dan McGee wrote:
I do see the use in this because I build regularly where I need to use the -d option, which unfortunately prevents a single dependency from being checked. Two years is a long time, so there has been plenty of time to reconsider, and I find the reasons in the bug report just as valid as they were two years ago.
I like the idea as I frequently use -d for x86_64 rebuilds and this would make it easier to build in a clean chroot. Allan
2008/7/1 Dan McGee <dpmcgee@gmail.com>:
On Tue, Jul 1, 2008 at 12:47 PM, Thomas Bächler <thomas@archlinux.org> wrote:
When a package A requires a package B at runtime, but B is not needed for building A or B cannot be installed while A is being built, rundepends=('B') can be used to add B to A's dependencies, omitting the dependency check at built time. --- scripts/makepkg.sh.in | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index c45d7e8..c809498 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -809,7 +809,7 @@ create_package() { for it in "${groups[@]}"; do echo "group = $it" >>.PKGINFO done - for it in "${depends[@]}"; do + for it in "${depends[@]} ${rundepends[@]}"; do echo "depend = $it" >>.PKGINFO done for it in "${optdepends[@]}"; do @@ -1287,7 +1287,7 @@ fi
unset pkgname pkgver pkgrel pkgdesc url license groups provides md5sums unset replaces depends conflicts backup source install build makedepends -unset optdepends options noextract +unset optdepends options noextract rundepends
if [ ! -f "$BUILDSCRIPT" ]; then error "$(gettext "%s does not exist.")" "$BUILDSCRIPT" --
I've been contemplating something like this for a while as well. What do others on the list think, is this getting to be too much, or does this make sense? I think I would be fine with it. We will need documentation (namely PKGBUILD.5.txt) to be patched as well in the final patch.
The proposed functionality is useful (I've encountered situation described by Thomas), but IMO this will add some confusion. Most people would just use depends even for run-time-only depends (when they're not cirlular, of course), so rundepends would be used only to workaround those circular builddepends. What I did to workaround the situation described by Thomas: * build A without depends=(B) * add depends=(B) and repackage with makepkg -R -- Roman Kyrylych (Роман Кирилич)
Thomas Bächler wrote:
When a package A requires a package B at runtime, but B is not needed for building A or B cannot be installed while A is being built, rundepends=('B') can be used to add B to A's dependencies, omitting the dependency check at built time.
Any chance of resubmitting this with the required documentation added (PKGBUILD.5.txt and addition to PKGBUILD.proto)? I think that this patch can be included once that is done. Allan
On Tue, Jul 15, 2008 at 1:27 AM, Allan McRae <allan@archlinux.org> wrote:
Thomas Bächler wrote:
When a package A requires a package B at runtime, but B is not needed for building A or B cannot be installed while A is being built, rundepends=('B') can be used to add B to A's dependencies, omitting the dependency check at built time.
Any chance of resubmitting this with the required documentation added (PKGBUILD.5.txt and addition to PKGBUILD.proto)? I think that this patch can be included once that is done.
Hello old thread! Anyone still interested in this? I'm not sure what the status on it is, other than it is probably my fault it got dropped on the floor. -Dan
Dan McGee wrote:
On Tue, Jul 15, 2008 at 1:27 AM, Allan McRae <allan@archlinux.org> wrote:
Thomas Bächler wrote:
When a package A requires a package B at runtime, but B is not needed for building A or B cannot be installed while A is being built, rundepends=('B') can be used to add B to A's dependencies, omitting the dependency check at built time.
Any chance of resubmitting this with the required documentation added (PKGBUILD.5.txt and addition to PKGBUILD.proto)? I think that this patch can be included once that is done.
Hello old thread! Anyone still interested in this? I'm not sure what the status on it is, other than it is probably my fault it got dropped on the floor.
The patch was never resubmitted and it is way down the priority list for me so I had forgotten all about it to. Anyway, I will be writing documentation for the package splitting stuff in makepkg soon so I could include that if no-one else does. I would prefer someone else did it... Allan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hey, This is already in Icadyptes' makepkg as runtimedeps=(). Not sure if runtimedeps=() matches the PKGBUILD variable naming scheme as much, but I would appreciate considering to use runtimedeps=() instead. Although if you go with rundepends=(), I'll probably switch over too. Glad that there is some interest for this in the mainline makepkg. Thanks, Teran On Thu, 16 Apr 2009 14:25:25 +1000 Allan McRae <allan@archlinux.org> wrote:
Dan McGee wrote:
On Tue, Jul 15, 2008 at 1:27 AM, Allan McRae <allan@archlinux.org> wrote:
Thomas Bächler wrote:
When a package A requires a package B at runtime, but B is not needed for building A or B cannot be installed while A is being built, rundepends=('B') can be used to add B to A's dependencies, omitting the dependency check at built time.
Any chance of resubmitting this with the required documentation added (PKGBUILD.5.txt and addition to PKGBUILD.proto)? I think that this patch can be included once that is done.
Hello old thread! Anyone still interested in this? I'm not sure what the status on it is, other than it is probably my fault it got dropped on the floor.
The patch was never resubmitted and it is way down the priority list for me so I had forgotten all about it to.
Anyway, I will be writing documentation for the package splitting stuff in makepkg soon so I could include that if no-one else does. I would prefer someone else did it...
Allan
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux)
iF4EAREIAAYFAknnIlkACgkQPsLC06eiyfHMWgEArEFHqFD70LUQshpMyNZhyC0z 2dshVN6dN9IOBlv3v/QBANkfGITXy8nic+QYdMRS/kRzp5MNjt7FJ5OI1v9mny9t =e8B/ -----END PGP SIGNATURE-----
Teran McKinney wrote:
Hey,
This is already in Icadyptes' makepkg as runtimedeps=(). Not sure if runtimedeps=() matches the PKGBUILD variable naming scheme as much, but I would appreciate considering to use runtimedeps=() instead. Although if you go with rundepends=(), I'll probably switch over too.
Glad that there is some interest for this in the mainline makepkg.
Thanks, Teran
This is just my opinion... but if you do not submit a patch with the changes you are using in Icadyptes, then I really don't care what you are doing. You have previously been encouraged to submit the changes you made for consideration and I have yet to see a single patch. Allan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I should have mentioned this in my reply to the Icadyptes makepkg thread, but I would have appreciated some replies showing interest in any particular change. Especially without any mentioned interest or replies I don't want to bother patching the mainstream Pacman. No replies for me implied no interest. Some of my changes are fairly radical and all are implemented messily, as I haven't even touched the man pages or docs. The more basic ones would be easy to recode. If you want any code examples for Icadyptes' makepkg changes, you'll have to look at the makepkg script <ftp://icadyptes.org/icadyptes/abs/core/base/pacman/makepkg>. But honestly, runtimedeps=() is such a simple change that it would take you just as long to import it and review it as it would for you to write it (asside from the docs). Same with arch=() implying arch=('any'). Cheers, Teran On Fri, 17 Apr 2009 04:27:42 +1000 Allan McRae <allan@archlinux.org> wrote:
Teran McKinney wrote:
Hey,
This is already in Icadyptes' makepkg as runtimedeps=(). Not sure if runtimedeps=() matches the PKGBUILD variable naming scheme as much, but I would appreciate considering to use runtimedeps=() instead. Although if you go with rundepends=(), I'll probably switch over too.
Glad that there is some interest for this in the mainline makepkg.
Thanks, Teran
This is just my opinion... but if you do not submit a patch with the changes you are using in Icadyptes, then I really don't care what you are doing. You have previously been encouraged to submit the changes you made for consideration and I have yet to see a single patch.
Allan
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux)
iF4EAREIAAYFAknodtUACgkQPsLC06eiyfG7SAEAnD/TiW0VC6Qtm2ljfezL+Rby 6yLHQEasI802tqjxWLMBALmiZ+IIsTYAQcJdO1i7U/2g5ZlU8X8FLcM7Us3lyfah =mACC -----END PGP SIGNATURE-----
On Thu, Apr 16, 2009 at 7:19 AM, Teran McKinney <sega01@go-beyond.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hey,
This is already in Icadyptes' makepkg as runtimedeps=(). Not sure if runtimedeps=() matches the PKGBUILD variable naming scheme as much, but I would appreciate considering to use runtimedeps=() instead. Although if you go with rundepends=(), I'll probably switch over too.
That seems inconsistent as we already have: DEPENDS makeDEPENDS optDEPENDS and now you want runtimeDEPS instead of runtimeDEPENDS or runDEPENDS?
Thomas Bächler wrote:
If destarch is added to a PKGBUILD,
I read that as de-starch and was confused for a while... :)
makepkg sets the architecture of the resulting package to $destarch instead of $CARCH. This is useful if you want to cross-create packages for one architecture on the other.
Using
arch=('i686') destarch='x86_64'
makes it possible to build multilib packages and to build grub without the export CARCH="x86_64" hack.
So when you are building the i686 packages, you have to comment out the destarch value? I think it would be better to use a flag like -D/--dest x86_64. Allan
On Tue, Jul 1, 2008 at 8:58 PM, Allan McRae <allan@archlinux.org> wrote:
Thomas Bächler wrote:
If destarch is added to a PKGBUILD,
I read that as de-starch and was confused for a while... :)
makepkg sets the architecture of the resulting package to $destarch instead of $CARCH. This is useful if you want to cross-create packages for one architecture on the other.
Using
arch=('i686') destarch='x86_64'
makes it possible to build multilib packages and to build grub without the export CARCH="x86_64" hack.
So when you are building the i686 packages, you have to comment out the destarch value? I think it would be better to use a flag like -D/--dest x86_64.
I wanted to make this same point too but I was afraid I interpreted the patch wrong. It doesn't seem intuitive to have to comment things in and out of the PKGBUILD. Of course, it is now just as easy to do: CARCH=blah makepkg which seems to make this patch not worth it? -Dan
Dan McGee wrote:
On Tue, Jul 1, 2008 at 8:58 PM, Allan McRae <allan@archlinux.org> wrote:
Thomas Bächler wrote:
If destarch is added to a PKGBUILD,
I read that as de-starch and was confused for a while... :)
makepkg sets the architecture of the resulting package to $destarch instead of $CARCH. This is useful if you want to cross-create packages for one architecture on the other.
Using
arch=('i686') destarch='x86_64'
makes it possible to build multilib packages and to build grub without the export CARCH="x86_64" hack.
So when you are building the i686 packages, you have to comment out the destarch value? I think it would be better to use a flag like -D/--dest x86_64.
I wanted to make this same point too but I was afraid I interpreted the patch wrong. It doesn't seem intuitive to have to comment things in and out of the PKGBUILD.
Of course, it is now just as easy to do: CARCH=blah makepkg
which seems to make this patch not worth it?
But CARCH=blah requires that blah is in the arch array which indicates that is can be built on that arch - not the case for grub. Would this make more sense? arch=('i686' 'x86_64) buildarch=('i686') To build for i686 just type "makepkg" on an i686 machine. To build for x86_64, type "makepkg -D x86_64" on an i686 machine. Typing "makepkg" on a x86_64 machine fails. I think this would be clearer. Allan
On Tue, Jul 1, 2008 at 11:11 PM, Allan McRae <allan@archlinux.org> wrote:
Dan McGee wrote:
On Tue, Jul 1, 2008 at 8:58 PM, Allan McRae <allan@archlinux.org> wrote:
Thomas Bächler wrote:
If destarch is added to a PKGBUILD,
I read that as de-starch and was confused for a while... :)
makepkg sets the architecture of the resulting package to $destarch instead of $CARCH. This is useful if you want to cross-create packages for one architecture on the other.
Using
arch=('i686') destarch='x86_64'
makes it possible to build multilib packages and to build grub without the export CARCH="x86_64" hack.
So when you are building the i686 packages, you have to comment out the destarch value? I think it would be better to use a flag like -D/--dest x86_64.
I wanted to make this same point too but I was afraid I interpreted the patch wrong. It doesn't seem intuitive to have to comment things in and out of the PKGBUILD.
Of course, it is now just as easy to do: CARCH=blah makepkg
which seems to make this patch not worth it?
But CARCH=blah requires that blah is in the arch array which indicates that is can be built on that arch - not the case for grub.
Oooohh, I guess I still didn't understand this then. So what is the deal here? We are just faking the arch extension at the end along with putting a different value in PKGINFO? I guess someone explaining the entire situation for stupid me would be best- I'm not very familiar on the grub build procedure, especially when it comes to building for "other" architectures.
Would this make more sense? arch=('i686' 'x86_64) buildarch=('i686')
To build for i686 just type "makepkg" on an i686 machine. To build for x86_64, type "makepkg -D x86_64" on an i686 machine. Typing "makepkg" on a x86_64 machine fails. I think this would be clearer.
I would rather not introduce a new variable for such a specific use case like this. It seems overkill to me, especially since i686/x86_64 is one of the few cases where the architectures share a lot in common. You wouldn't really do something along the lines of i686/ppc for instance. -Dan
Allan McRae schrieb:
But CARCH=blah requires that blah is in the arch array which indicates that is can be built on that arch - not the case for grub.
Indeed.
Would this make more sense? arch=('i686' 'x86_64) buildarch=('i686')
To build for i686 just type "makepkg" on an i686 machine. To build for x86_64, type "makepkg -D x86_64" on an i686 machine. Typing "makepkg" on a x86_64 machine fails. I think this would be clearer.
Yeah, I just saw that this makes much more sense for grub, as you need the package for both architectures (right now, we actually change a comment everytime we build it). However, my motivation was that right now I am building some multilib stuff and have packages that always have to be built on i686 and installed on x86_64. So at the end of the build() procedure I need to do 'export CARCH="x86_64"', which is a hack that doesn't work with -L for example. Using a -D option would mean that I have to build 20 or 30 packages with '-D x86_64' all the time. My goal was to make the build procedure for these packages intuitive enough, so you can't build them "wrong".
Thomas Bächler wrote:
Would this make more sense? arch=('i686' 'x86_64) buildarch=('i686')
To build for i686 just type "makepkg" on an i686 machine. To build for x86_64, type "makepkg -D x86_64" on an i686 machine. Typing "makepkg" on a x86_64 machine fails. I think this would be clearer.
Yeah, I just saw that this makes much more sense for grub, as you need the package for both architectures (right now, we actually change a comment everytime we build it). However, my motivation was that right now I am building some multilib stuff and have packages that always have to be built on i686 and installed on x86_64. So at the end of the build() procedure I need to do 'export CARCH="x86_64"', which is a hack that doesn't work with -L for example.
Using a -D option would mean that I have to build 20 or 30 packages with '-D x86_64' all the time. My goal was to make the build procedure for these packages intuitive enough, so you can't build them "wrong".
Just getting an indication of how common this is. The multilib stuff in [community] all takes the i686 package as the source and just moves the files to the new locations. Is there some reason that you cannot use that approach. Wouldn't all packages you are wanting to make a multilib package for have an i686 package floating about. Also, with that approach you can actually make the package on the target architecture. Allan
Allan McRae schrieb:
Just getting an indication of how common this is. The multilib stuff in [community] all takes the i686 package as the source and just moves the files to the new locations. Is there some reason that you cannot use that approach. Wouldn't all packages you are wanting to make a multilib package for have an i686 package floating about. Also, with that approach you can actually make the package on the target architecture.
The approach taken in community doesn't work very well, as putting a library package into a different path poses problems. Just one example: glibc has the path /usr/lib/gconv hardcoded, now we load the 32 bit glibc on a 64 bit system and it tries to load the modules from /usr/lib/gconv, all of which are 64 bit binaries, thus incompatible. Similar problems exist for alsa-lib, pango, gtk and maybe others. In the community/AUR packages, these are worked around by environment variables where possible, but in most cases they are just being ignored. Thus I started to look into rebuilding all packages required on a 32 bit system, adjusting the paths correctly and stripping all unnecessary files. This is supposed to be a _clean_ and slim 32 bit runtime without a build environment. Right now I got enough libraries to make nspluginwrapper (built from source!) and flashplugin work. My goal for now is to get nspluginwrapper+flash and wine to work on a 64 bit archlinux system. Maybe later I want to add all libraries necessary to install and run Google Earth. This task motivated the destarch=, STRIP_DIRS and rundepends suggestions I posted: In my PKGBUILDs, I would then use arch=('i686') destarch='x86_64' makedepends=('glibc' 'foo') rundepends=('glibc-32bit' 'foo-32bit') to "cross-compile" the packages on my full arch32 system. I hope this clarifies my wishes.
2008/7/2 Thomas Bächler <thomas@archlinux.org>:
Allan McRae schrieb:
Just getting an indication of how common this is. The multilib stuff in [community] all takes the i686 package as the source and just moves the files to the new locations. Is there some reason that you cannot use that approach. Wouldn't all packages you are wanting to make a multilib package for have an i686 package floating about. Also, with that approach you can actually make the package on the target architecture.
The approach taken in community doesn't work very well, as putting a library package into a different path poses problems. Just one example: glibc has the path /usr/lib/gconv hardcoded, now we load the 32 bit glibc on a 64 bit system and it tries to load the modules from /usr/lib/gconv, all of which are 64 bit binaries, thus incompatible. Similar problems exist for alsa-lib, pango, gtk and maybe others. In the community/AUR packages, these are worked around by environment variables where possible, but in most cases they are just being ignored.
Thus I started to look into rebuilding all packages required on a 32 bit system, adjusting the paths correctly and stripping all unnecessary files. This is supposed to be a _clean_ and slim 32 bit runtime without a build environment. Right now I got enough libraries to make nspluginwrapper (built from source!) and flashplugin work.
My goal for now is to get nspluginwrapper+flash and wine to work on a 64 bit archlinux system. Maybe later I want to add all libraries necessary to install and run Google Earth.
This task motivated the destarch=, STRIP_DIRS and rundepends suggestions I posted: In my PKGBUILDs, I would then use
arch=('i686') destarch='x86_64' makedepends=('glibc' 'foo') rundepends=('glibc-32bit' 'foo-32bit')
to "cross-compile" the packages on my full arch32 system. I hope this clarifies my wishes.
Ah, now this {make,run}depends thing makes sense to me. <just-thinking> Though, for more clarity, IMHO it could be nicier for makepkg -s to install _only_ makedepends, and if pkgA is both run-time and build-time dependcy, then write it as: makedepends=('pkgA') depends=('pkgA') but obviously that's not backwards compatible, and huge amount of packages would have to be changed, and many packages would have dependencies duplicated in 2 variables, so Thomas' proposal of introducing rundepends makes perfect sense and is the best way here </just-thinking> -- Roman Kyrylych (Роман Кирилич)
On Thu, Jul 3, 2008 at 1:42 PM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Ah, now this {make,run}depends thing makes sense to me. <just-thinking> Though, for more clarity, IMHO it could be nicier for makepkg -s to install _only_ makedepends, and if pkgA is both run-time and build-time dependcy, then write it as: makedepends=('pkgA') depends=('pkgA') but obviously that's not backwards compatible, and huge amount of packages would have to be changed, and many packages would have dependencies duplicated in 2 variables, so Thomas' proposal of introducing rundepends makes perfect sense and is the best way here </just-thinking>
Yeah, I also think that this would be a cleaner design but is not practical at all :P
participants (8)
-
Aaron Griffin
-
Allan McRae
-
Dan McGee
-
Miklos Vajna
-
Roman Kyrylych
-
Teran McKinney
-
Thomas Bächler
-
Xavier