On Fri, Jan 17, 2014 at 08:38:08PM +1000, Allan McRae wrote: > 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. >
Agreed. > > 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. > Right, the pkgsuffix isn't considered at all when naming the source tarball. > > 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. > Agreed. > > 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? A pkgsuffix of '-llama' on the linux package would result in: linux-llama linux-headers-llama linux-docs-llama This isn't what people normally do with modified linux packages, but I don't think it's any less/more right.
