Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#40711 - [pkgbuild-introspection] mkaurball doesn't set $CARCH
Attached to Project:
Community Packages
Opened by (Det) - Thursday, 05 June 2014, 15:04 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 06 August 2014, 17:38 GMT
Opened by (Det) - Thursday, 05 June 2014, 15:04 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 06 August 2014, 17:38 GMT
|
DetailsCurrently, mkaurball doesn't understand $CARCH.
This means that a PKGBUILD that says: _arch=i386 [ "$CARCH" = 'x86_64' ] && _arch=amd64 source=("$_arch.deb") Produces the following on a 64-bit system in the .AURINFO: source = i386.deb |
This task depends upon
Closed by Dave Reisner (falconindy)
Wednesday, 06 August 2014, 17:38 GMT
Reason for closing: Won't fix
Additional comments about closing: Needs fixing in makepkg to provide arch specific deps which AURINFO can then support.
Wednesday, 06 August 2014, 17:38 GMT
Reason for closing: Won't fix
Additional comments about closing: Needs fixing in makepkg to provide arch specific deps which AURINFO can then support.
It's just more fool-proof, because if I do:
depends=('lib32-cairo')
[ "$CARCH" = 'i686' ] && depends=('cairo')
_arch=i386
[ "$CARCH" = 'x86_64' ] && _arch=amd64
source=("$_arch.deb")
I'm returned with:
depends = lib32-cairo
source = i386.deb
Currently, we get a mix, which is a lot worse.
When that happens I'd much rather have them be as 'consistent' as possible, and not include i686 dependencies and x86_64 sources.
If we can prevent that, then I don't get what your problem is.
@Scimmia, if that means the current implementation really is that hard to fix, then I guess I've got my answer. Thanks.