[pacman-dev] [PATCH] Add support for arch='all' to makepkg
Hi! Today I have started adding support for noarch packages. This is the first step. The attached patch adds support for arch='all' to makepkg. It's very simple because it just sets CARCH to all and then everything else goes as usual. When we'll add support for subpackages - we'll have to make additional checks to be sure we can build -i686/-x86_64 package and -all package from one PKGBUILD. This depends on a way we implement subpackages and can be modified later. So far, pacman-git is able to install packages built with the modified makepkg, and shows "Architecture: all" on -Qi. I'll post patches for other scripts soon. How to test it: 1) get any font/cursor/etc PKGBUILD from AUR, 2) replace arch=('i686' 'x86_64') with arch='all' 3) use the patched makepkg to build the package 4) use pacman -U (git version, 3.0.x fails) to install the package 5) do pacman -Qi -- Roman Kyrylych (Роман Кирилич)
2007/10/30, Roman Kyrylych <roman.kyrylych@gmail.com>:
Hi!
Today I have started adding support for noarch packages. This is the first step. The attached patch adds support for arch='all' to makepkg. It's very simple because it just sets CARCH to all and then everything else goes as usual.
When we'll add support for subpackages - we'll have to make additional checks to be sure we can build -i686/-x86_64 package and -all package from one PKGBUILD. This depends on a way we implement subpackages and can be modified later.
So far, pacman-git is able to install packages built with the modified makepkg, and shows "Architecture: all" on -Qi.
I'll post patches for other scripts soon.
How to test it: 1) get any font/cursor/etc PKGBUILD from AUR, 2) replace arch=('i686' 'x86_64') with arch='all' 3) use the patched makepkg to build the package 4) use pacman -U (git version, 3.0.x fails) to install the package 5) do pacman -Qi
OK, here is a patch for gensync and updatesync. repo-add and repo-remove don't need any modifications. -- Roman Kyrylych (Роман Кирилич)
On 10/30/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/10/30, Roman Kyrylych <roman.kyrylych@gmail.com>:
Hi!
Today I have started adding support for noarch packages. This is the first step. The attached patch adds support for arch='all' to makepkg. It's very simple because it just sets CARCH to all and then everything else goes as usual.
When we'll add support for subpackages - we'll have to make additional checks to be sure we can build -i686/-x86_64 package and -all package from one PKGBUILD. This depends on a way we implement subpackages and can be modified later.
So far, pacman-git is able to install packages built with the modified makepkg, and shows "Architecture: all" on -Qi.
I'll post patches for other scripts soon.
How to test it: 1) get any font/cursor/etc PKGBUILD from AUR, 2) replace arch=('i686' 'x86_64') with arch='all' 3) use the patched makepkg to build the package 4) use pacman -U (git version, 3.0.x fails) to install the package 5) do pacman -Qi
OK, here is a patch for gensync and updatesync. repo-add and repo-remove don't need any modifications.
Both of these look good to me. One question though - are we sure we want to use "all" as the architecture? It makes sense grammatically, but is it the best name?
2007/10/30, Aaron Griffin <aaronmgriffin@gmail.com>:
On 10/30/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/10/30, Roman Kyrylych <roman.kyrylych@gmail.com>:
Hi!
Today I have started adding support for noarch packages. This is the first step. The attached patch adds support for arch='all' to makepkg. It's very simple because it just sets CARCH to all and then everything else goes as usual.
When we'll add support for subpackages - we'll have to make additional checks to be sure we can build -i686/-x86_64 package and -all package from one PKGBUILD. This depends on a way we implement subpackages and can be modified later.
So far, pacman-git is able to install packages built with the modified makepkg, and shows "Architecture: all" on -Qi.
I'll post patches for other scripts soon.
How to test it: 1) get any font/cursor/etc PKGBUILD from AUR, 2) replace arch=('i686' 'x86_64') with arch='all' 3) use the patched makepkg to build the package 4) use pacman -U (git version, 3.0.x fails) to install the package 5) do pacman -Qi
OK, here is a patch for gensync and updatesync. repo-add and repo-remove don't need any modifications.
Both of these look good to me. One question though - are we sure we want to use "all" as the architecture? It makes sense grammatically, but is it the best name?
I just had to pick one. :-) Another variant I like is 'any'. pacman -Qi outputs: Architecture: all - OK Architecture: any - OK, probably even better Architecture: noarch - huh? sounds bad ;-) -- Roman Kyrylych (Роман Кирилич)
I just had to pick one. :-) Another variant I like is 'any'. pacman -Qi outputs: Architecture: all - OK Architecture: any - OK, probably even better Architecture: noarch - huh? sounds bad ;-)
Architecture: generic ?
2007/10/30, Gabriel C <nix.or.die@googlemail.com>:
I just had to pick one. :-) Another variant I like is 'any'. pacman -Qi outputs: Architecture: all - OK Architecture: any - OK, probably even better Architecture: noarch - huh? sounds bad ;-)
Architecture: generic ?
hm, didn't even thought about it. :) the problem is that then filenames wil contain -generic suffix which is too long IMO. -- Roman Kyrylych (Роман Кирилич)
On 10/30/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/10/30, Gabriel C <nix.or.die@googlemail.com>:
I just had to pick one. :-) Another variant I like is 'any'. pacman -Qi outputs: Architecture: all - OK Architecture: any - OK, probably even better Architecture: noarch - huh? sounds bad ;-)
Architecture: generic ?
hm, didn't even thought about it. :) the problem is that then filenames wil contain -generic suffix which is too long IMO.
I like either 'generic' or 'any'. Dan?
2007/10/30, Aaron Griffin <aaronmgriffin@gmail.com>:
On 10/30/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/10/30, Gabriel C <nix.or.die@googlemail.com>:
I just had to pick one. :-) Another variant I like is 'any'. pacman -Qi outputs: Architecture: all - OK Architecture: any - OK, probably even better Architecture: noarch - huh? sounds bad ;-)
Architecture: generic ?
hm, didn't even thought about it. :) the problem is that then filenames wil contain -generic suffix which is too long IMO.
I like either 'generic' or 'any'. Dan?
Hm, ok, let it be one of them. I prefer 'any' though. -- Roman Kyrylych (Роман Кирилич)
On 10/31/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/10/30, Aaron Griffin <aaronmgriffin@gmail.com>:
On 10/30/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/10/30, Gabriel C <nix.or.die@googlemail.com>:
I just had to pick one. :-) Another variant I like is 'any'. pacman -Qi outputs: Architecture: all - OK Architecture: any - OK, probably even better Architecture: noarch - huh? sounds bad ;-)
Architecture: generic ?
hm, didn't even thought about it. :) the problem is that then filenames wil contain -generic suffix which is too long IMO.
I like either 'generic' or 'any'. Dan?
Hm, ok, let it be one of them. I prefer 'any' though.
Don't want to bikeshed this, but let's put this in context: Current package names: pidgin-2.2.2-2-i686.pkg.tar.gz pidgin-2.2.2-2-x86_64.pkg.tar.gz pidgin-2.2.2-2-ppc.pkg.tar.gz ... Proposed generic architecture names: pidgin-2.2.2-2-all.pkg.tar.gz pidgin-2.2.2-2-generic.pkg.tar.gz pidgin-2.2.2-2-any.pkg.tar.gz pidgin-2.2.2-2-???.pkg.tar.gz My only concern here is that "any", "all", and "generic" are all a bit useless out of context. In the former package names, the context is immediately recognized. In the latter, do any of those really make sense? The problem is "anyarch" or "genericarch" or variants are way too long. Damn, another patch lost to politics. :) If I had to pick from the above, I'd go with "generic" I think because it carries the most context with it, just like an architecture name would. -Dan
2007/10/31, Dan McGee <dpmcgee@gmail.com>:
On 10/31/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/10/30, Aaron Griffin <aaronmgriffin@gmail.com>:
On 10/30/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/10/30, Gabriel C <nix.or.die@googlemail.com>:
I just had to pick one. :-) Another variant I like is 'any'. pacman -Qi outputs: Architecture: all - OK Architecture: any - OK, probably even better Architecture: noarch - huh? sounds bad ;-)
Architecture: generic ?
hm, didn't even thought about it. :) the problem is that then filenames wil contain -generic suffix which is too long IMO.
I like either 'generic' or 'any'. Dan?
Hm, ok, let it be one of them. I prefer 'any' though.
Don't want to bikeshed this, but let's put this in context:
Current package names: pidgin-2.2.2-2-i686.pkg.tar.gz pidgin-2.2.2-2-x86_64.pkg.tar.gz pidgin-2.2.2-2-ppc.pkg.tar.gz ...
Proposed generic architecture names: pidgin-2.2.2-2-all.pkg.tar.gz pidgin-2.2.2-2-generic.pkg.tar.gz pidgin-2.2.2-2-any.pkg.tar.gz pidgin-2.2.2-2-???.pkg.tar.gz
My only concern here is that "any", "all", and "generic" are all a bit useless out of context. In the former package names, the context is immediately recognized. In the latter, do any of those really make sense? The problem is "anyarch" or "genericarch" or variants are way too long.
Damn, another patch lost to politics. :) If I had to pick from the above, I'd go with "generic" I think because it carries the most context with it, just like an architecture name would.
Damn, we should just pick a name. I'd go with 'any' here (because it's shorter than 'generic'), but feel free to choose whatever you like. Anyway this can be changed later, until we implement this functionality in devtools, db-* scripts, web backend and AUR. Only then we can start using this not just for testing. -- Roman Kyrylych (Роман Кирилич)
On 10/31/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Damn, we should just pick a name. I'd go with 'any' here (because it's shorter than 'generic'), but feel free to choose whatever you like. Anyway this can be changed later, until we implement this functionality in devtools, db-* scripts, web backend and AUR. Only then we can start using this not just for testing.
I agree. Considering filenames are stored in the DBs we can always change it later and break nothing. Roman, could you resubmit with "any" instead of all?
2007/10/31, Aaron Griffin <aaronmgriffin@gmail.com>:
On 10/31/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Damn, we should just pick a name. I'd go with 'any' here (because it's shorter than 'generic'), but feel free to choose whatever you like. Anyway this can be changed later, until we implement this functionality in devtools, db-* scripts, web backend and AUR. Only then we can start using this not just for testing.
I agree. Considering filenames are stored in the DBs we can always change it later and break nothing.
Roman, could you resubmit with "any" instead of all?
Here it is, combined into one patch. -- Roman Kyrylych (Роман Кирилич)
On 10/31/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/10/31, Aaron Griffin <aaronmgriffin@gmail.com>:
On 10/31/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Damn, we should just pick a name. I'd go with 'any' here (because it's shorter than 'generic'), but feel free to choose whatever you like. Anyway this can be changed later, until we implement this functionality in devtools, db-* scripts, web backend and AUR. Only then we can start using this not just for testing.
I agree. Considering filenames are stored in the DBs we can always change it later and break nothing.
Roman, could you resubmit with "any" instead of all?
Here it is, combined into one patch.
Pushed to my working branch. -Dan
participants (4)
-
Aaron Griffin
-
Dan McGee
-
Gabriel C
-
Roman Kyrylych