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

Dave Reisner d at falconindy.com
Thu Jan 16 20:49:16 EST 2014

On Thu, Jan 16, 2014 at 11:54:24PM +0000, Jerome Leclanche wrote:
> On Thu, Jan 16, 2014 at 10:15 PM, Dave Reisner <d at falconindy.com> 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.
> >
> > 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=packages/linux#n353
> >
> Where else would you see it used? Would it be appropriate for git
> packages? (eg pkgsuffix=git) And if so, would introducing a $pkgprefix
> make sense, for symmetry?

No, this probably isn't appropriate for git packages, since it requires
not just a package name change, but also a pkgver function, a source
array change, and maybe a prepare function (or changes to the build).

This is strictly a user convenience mechanism that's currently painful
to implement externally compared to the ease of which it can be offered
by makepkg proper.


More information about the pacman-dev mailing list