[pacman-dev] [RFC] Introduce pkgsuffix to PKGBUILD spec

[Dave Reisner]

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.