On Wed, Jun 20, 2012 at 10:56 AM, Allan McRae <[email protected]> wrote: > On 21/06/12 00:31, Florian Pritz wrote: >> On 06/20/2012 05:28 AM, Allan McRae wrote: >>> This does not >>> handle split packages that have different architectures. >> >> Split packages use pkgbase rather than pkgname[@] as the name for the >> logfile, so even if you override arch from within a package function my >> patch should work. >> >> Could someone else take a look? >> > > > On 21/06/12 00:31, Florian Pritz wrote:> On 06/20/2012 05:28 AM, Allan > McRae wrote: >>> This does not >>> handle split packages that have different architectures. >> >> Split packages use pkgbase rather than pkgname[@] as the name for the >> logfile, so even if you override arch from within a package function my >> patch should work. >> >> Could someone else take a look? >> > > > What should the log file names be for this PKGBUILD? > > pkgname=('foo' 'bar') > pkgver=1 > pkgrel=1 > arch=('i686' 'x86_64') > > package_foo() { > : > } > > package_bar() { > arch=('any') > } > > > What about for this one? > > pkgname=('foo' 'bar') > pkgver=1 > pkgrel=1 > arch=('any') > > package_foo() { > : > } > > package_bar() { > arch=('i686' 'x86_64') > } > > > > Now... I actually like the actual build arch listed in the log file > name. If I have an "arch=any" package that fails only on a certain > architecture, it is handy to know what arch it was build on. So I see > the current behaviour as a feature and not a bug. > > Allan > >
I'm the one who first reported this makepkg behaviour on the pacman IRC channel. My initial problem was simply that it wasn't the filename I would expect. As Allan said, having the actual CARCH of the system that a package was built on might be useful for debugging so I don't mind if we keep the current behaviour. In case we want to change it, I did tested the proposed patch. For unsplitted 'any' arch package it works well: foo-1-1-any-build.log foo-1-1-any-package.log For Allan's first example: As we are building both 'x86_64' and 'any' packages and both package share common build (and check) logs, using $CARCH makes sense here. foo-1-1-x86_64-build.log foo-1-1-x86_64-package_bar.log foo-1-1-x86_64-package_foo.log For Allan's second example: We're basically back to square one with the roles reversed. It would be better to use $CARCH like in the first example. foo-1-1-any-build.log foo-1-1-any-package_bar.log foo-1-1-any-package_foo.log In conclusion, if we decide to change the current behavior, the best way to to do it, IMHO, would be: - use logarch="any" for unsplitted 'any' arch package or splitted package containing only 'any' arch packages. - use logarch=$CARCH in all the other cases. Eric
