[pacman-dev] [PATCH] Add support for arch='all' to makepkg

[Roman Kyrylych]

2007/10/31, Dan McGee <dpmcgee at gmail.com>:
> On 10/31/07, Roman Kyrylych <roman.kyrylych at gmail.com> wrote:
> > 2007/10/30, Aaron Griffin <aaronmgriffin at gmail.com>:
> > > On 10/30/07, Roman Kyrylych <roman.kyrylych at gmail.com> wrote:
> > > > 2007/10/30, Gabriel C <nix.or.die at 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 (Роман Кирилич)