Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#15870 - [pacman 3.3.0-2] 'any' architecture is not mentionned in PKGBUILD man page
Attached to Project:
Pacman
Opened by solsTiCe (zebul666) - Sunday, 09 August 2009, 07:40 GMT
Last edited by Dan McGee (toofishes) - Monday, 07 September 2009, 20:25 GMT
Opened by solsTiCe (zebul666) - Sunday, 09 August 2009, 07:40 GMT
Last edited by Dan McGee (toofishes) - Monday, 07 September 2009, 20:25 GMT
|
DetailsDescription:
in the 'arch' paragraph of the man page of PKGBUILD, there is no mention of the new 'any' arch variable. it could explain when to use it and give as must detail to avoid error in using this new arch. |
This task depends upon
Closed by Dan McGee (toofishes)
Monday, 07 September 2009, 20:25 GMT
Reason for closing: Fixed
Additional comments about closing: commit 2e7c569950
Monday, 07 September 2009, 20:25 GMT
Reason for closing: Fixed
Additional comments about closing: commit 2e7c569950
that's for vim package
this must apply too to the vim package in [testing] too.
But I don't know... There is no specific arch handling done in the whole pacman source. You can use whatever arch you want.
The arch limitations are in the arch specific side, db tools, etc.. Nothing was done in the pacman source for handling the any arch.
Afaik, it was all done in dbscripts : http://projects.archlinux.org/?p=dbscripts.git;a=summary
Based on this, maybe we should remove arch checking from PKGBUILD.vim as well, I don't know..
Currently the man page looks like:
arch (array)
Defines on which architectures the given package is available (e.g.
arch=('i686' 'x86_64')).
Does adding this at the end sound fine?:
Packages that contain no architecture specific files may use arch=('any').
makepkg just writes the arch inside .PKGINFO, repo-add in desc, but pacman does not do anything with it.
Maybe in the future, pacman could check that the arch matches a configuration in pacman.conf, but it is still not pacman which gives sense to the 'any' arch.
This choice is left to the distribution using it. For instance, Arch gives the sense of 'any' in dbscripts.
/usr/share/vim/syntax/PKGBUILD.vim is in pacman-contrib only
$ grep -RFI '"any"' *
lib/libalpm/trans.c: if(strcmp(pkgarch,arch) && strcmp(pkgarch,"any")) {
$ grep -RFI "'any'" *
NEWS: - arch=('any') support (
FS#8153)contrib/updatesync: if [ "$arch" = 'any' ]; then
contrib/updatesync: CARCH='any'
contrib/gensync: if [ "$arch" = 'any' ]; then
contrib/gensync: CARCH='any'
doc/pacman.conf.5.txt: architecture 'any' can always be installed, as they are meant to be
pactest/tests/upgrade084.py:self.description = "Install a package ('any' architecture)"
pactest/tests/upgrade084.py:p.arch = 'any'
scripts/makepkg.sh.in: if [ "$arch" = 'any' ]; then
scripts/makepkg.sh.in: CARCH='any'
scripts/makepkg: if [ "$arch" = 'any' ]; then
scripts/makepkg: CARCH='any'
Then I completely agree with the change Allan suggested for PKGBUILD man page.
And we also need to fix PKGBUILD.vim