Hi, I've been parsing a large number of PKGBUILDs recently, and in doing so, learned a lot about how people misuse PKGBUILDs. One case in particular that intrigues me is the core/linux PKGBUILD in Arch[1] which uses code generation to create the package_* functions. This is mainly done for the purposes of making users' lives easier, as they have fewer changes they need to maintain. On the other hand, this makes the PKGBUILD far harder to parse, and perhaps arguably harder to read. I thought about how else this could be solved and came up with the idea of introducing a 'pkgsuffix' variable in the PKGBUILD spec. The name should make it obvious as to what it does -- for any package defined in the PKGBUILD, append $pkgsuffix to the name. I've already written an initial patch for makepkg which ends up being quite simple. Implementation details: The suffix should be as transparent as possible. The only time the full with-suffix names appear is in the final package output (tarball name and .PKGINFO). That means packages (when referenced via the --pkg flag) will still be the non-suffixed name. Source packages are a little trickier. I can imagine cases for including or excluding the suffix in the tarball name, but I went with the exclusion route. Note that the pkgname portion of the source tarball name is somewhat insignificant, as you could have pkgbase=voltron, pkgname=daibazaal, and the source tarball name would be voltron. Appending the suffix is, IMO, equally insigificant since the suffix applies to the output package names, not the pkgbase. Something that surfaced early in testing is a question about dependencies. My patch currently implicitly adds provides and conflicts for the pkgname sans-suffix. I think that there's a lot more cases where this is the right, rather than wrong, thing to do. At the moment, these added dependencies are unversioned. Thoughts? d [1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=p...