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

[Allan McRae]

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