Hey.
I'd like to hear reasons. I don't really feel that "RPM and DEB do it" is a good enough reason. I mean, if that reason was good enough, we'd be using RPM/DEB in place of pacman packages.
:)
The way I see it, I don't think pacman needs to know the architecture it's running on. Installing "pkg-foo" should be no different on i686 or PPC. Therefore, I think that adding the architecture suffix is extra information that's not really needed.
What is gained by having this suffix?
brr. Sorry, i really dont know why we started to using $ARCH suffix in frugalware, vmiklos will answer this. But. In my opinion if a user pulls a package from anywhere, from web or from ftp or just he is store packages in cd or dvd, etc, then he/she can see that what is this pack. I mean for which architecture. Just seeing the filename and you know that foo-1.0-1-x86_64 is for x86_64 archs, -i686 for i686 archs. So users not confused to see foo-1.0-1 and foo-1.0-1 and user just thinks, "what the hell, two same package? install that one then" And maybe he install an i686 package to x86_64 arch :) I know you will answer something like this: we store our packages in distro-i686/ distro-x86_64/ dirs and why need an extra SUFFIX. Because of that. If you find a package somewhere or you got a mirror or a backup sometimes you want to know from the filename that package is for what architecture. Think a good idea this, and this seems some "standard" nowadays. I know you said not to say that RPM/DEB do this :) but then i says most major distribution do this scheme whatever its pkgmanager. (except slackware) Regards -krix-