[pacman-dev] [RFC] Introduce pkgsuffix to PKGBUILD spec
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=p...
On Thu, Jan 16, 2014 at 10:15 PM, Dave Reisner d@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=p...
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?
J. Leclanche
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@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=p...
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.
d
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
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.
participants (3)
-
Allan McRae
-
Dave Reisner
-
Jerome Leclanche