On 17/01/14 08:15, Dave Reisner wrote: > 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.
I'm not convinced we need a feature added for one package, but if it is a fairly non-intrusive patch, that will be OK. > 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. As long as pkgbase is set to the pkgname without the suffix. I have a patch that make sure pkgbase and the base version is included in the .PKGINFO file if different so that we can identify source tarballs from package files. > 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. provide should probably be versioned. > Thoughts? I never understood the linux PKGBUILD. Surely there is a lot more to do when maintaining a different kernel version than just change the name. Also, what package names do you end up with using your patch? linux-ck, linux-docs-ck, linux-headers-ck? Or linux-ck, linux-ck-docs, linux-ck-headers? Allan
