[pacman-dev] Matching split packages to PKGBUILDs
I was under the impression that the naming convention for split packages was $pkgbase-$pkgname. I've used this scheme in bauerbill to determine the corresponding PKGBUILD of split packages in $repo.abs.tar.gz. This works for all packages in the kernel26 PKGBUILD, for example, but someone has discovered that this does not work with dhclient. Is there simply no official rule for this or should dhclient actually be names "dhcp-client"? I'm hoping for that latter with the expectation that the name was not changed because the package was named "dhclient" before the advent of split packages. Should I file a bug report and request that the package be renamed "dhcp-client" and provide "dhclient"? If not, how can I sanely determine the corresponding PKGBUILD for packages such as dhclient which do not follow any naming convention that would identify the matching PKGBUILD? Would it be possible to include symlinks or duplicate PKGBUILDs in $repo.abs.tar.gz to enable applications to determine this? I know that some of you feel that the sole purpose of makepkg is to build packages and consequently have no regard for anything else one might want to do with PKGBUILDs, but this is very unfortunate as it severely limits the development of complementary tools. While I see the superficial simplicity of using bash for PKGBUILDs and the convenience of split PKGBUILDs, I really think this is going in the wrong direction. There is a difference between simplicity and laziness, and the trade-off of versatility and elegance is a considerable disadvantage of this direction, as previous discussions here have shown. Regards, Your friendly yet frustrated contributor.
On Thu, 21 Jan 2010 12:46:01 +0100, Xyne
If not, how can I sanely determine the corresponding PKGBUILD for packages such as dhclient which do not follow any naming convention that would identify the matching PKGBUILD? Would it be possible to include symlinks or duplicate PKGBUILDs in $repo.abs.tar.gz to enable applications to determine this?
There is no naming convention and there shouldn't be any. Just read the pkgbase var from the repo or BASE from the package itself to determine the base PKGBUILD. -- Pierre Schmitz, https://users.archlinux.de/~pierre
There is no naming convention and there shouldn't be any. Just read the pkgbase var from the repo or BASE from the package itself to determine the base PKGBUILD.
Thanks, I was unaware of that.
Xyne wrote:
I was under the impression that the naming convention for split packages was $pkgbase-$pkgname. I've used this scheme in bauerbill to determine the corresponding PKGBUILD of split packages in $repo.abs.tar.gz. This works for all packages in the kernel26 PKGBUILD, for example, but someone has discovered that this does not work with dhclient.
No rule was ever made.
Is there simply no official rule for this or should dhclient actually be names "dhcp-client"? I'm hoping for that latter with the expectation that the name was not changed because the package was named "dhclient" before the advent of split packages. Should I file a bug report and request that the package be renamed "dhcp-client" and provide "dhclient"?
No, there is no restriction on naming of packages from split PKGBUILDs. You are going to love device-mapper...
If not, how can I sanely determine the corresponding PKGBUILD for packages such as dhclient which do not follow any naming convention that would identify the matching PKGBUILD? Would it be possible to include symlinks or duplicate PKGBUILDs in $repo.abs.tar.gz to enable applications to determine this?
Look at %BASE% in <DBPath>/sync/<repo>/$pkgname-$pkgver/desc. Symlinks to folders with split-package names was discussed and rejected for Arch SVN package management (from which the ABS tarballs are created).
I know that some of you feel that the sole purpose of makepkg is to build packages and consequently have no regard for anything else one might want to do with PKGBUILDs, but this is very unfortunate as it severely limits the development of complementary tools. While I see the superficial simplicity of using bash for PKGBUILDs and the convenience of split PKGBUILDs, I really think this is going in the wrong direction. There is a difference between simplicity and laziness, and the trade-off of versatility and elegance is a considerable disadvantage of this direction, as previous discussions here have shown.
Thats nice... I have yet to see a proposal that could replace the current bash based PKGBUILDs with out loosing a great deal of the simplicity and flexibility of the PKGBUILD format. That includes the format you have proposed. Until this mythical format appears, the "lazyness" will continue as that is what the situation warrants. Allan
Thats nice... I have yet to see a proposal that could replace the current bash based PKGBUILDs with out loosing a great deal of the simplicity and flexibility of the PKGBUILD format. That includes the format you have proposed. Until this mythical format appears, the "lazyness" will continue as that is what the situation warrants.
The format that I've "proposed" is just an incomplete idea that comes from thinking out loud. Unfortunately, instead of getting useful feedback or starting any sort of reasonable discussion, the general response has been anything but constructive. I had hoped that others would contribute ideas and suggestions but unfortunately most people seem to have reached that level of complacency that they no longer have any inclination to think differently about something they've been doing one way for years, because "it just works". It's like dealing with a bunch of grumpy old men who just keep muttering "that'll never work" without trying to think of a way that it might. It's the same attitude that leads to the "submit a patch or else I won't even look at it" mantra. /snip I'll leave it at that before this becomes too contentious. Thanks for the reply.
On Thu, Jan 21, 2010 at 12:46 PM, Xyne
I was under the impression that the naming convention for split packages was $pkgbase-$pkgname. I've used this scheme in bauerbill to determine the corresponding PKGBUILD of split packages in $repo.abs.tar.gz. This works for all packages in the kernel26 PKGBUILD, for example, but someone has discovered that this does not work with dhclient.
Is there simply no official rule for this or should dhclient actually be names "dhcp-client"? I'm hoping for that latter with the expectation that the name was not changed because the package was named "dhclient" before the advent of split packages. Should I file a bug report and request that the package be renamed "dhcp-client" and provide "dhclient"?
If not, how can I sanely determine the corresponding PKGBUILD for packages such as dhclient which do not follow any naming convention that would identify the matching PKGBUILD? Would it be possible to include symlinks or duplicate PKGBUILDs in $repo.abs.tar.gz to enable applications to determine this?
I know that some of you feel that the sole purpose of makepkg is to build packages and consequently have no regard for anything else one might want to do with PKGBUILDs, but this is very unfortunate as it severely limits the development of complementary tools. While I see the superficial simplicity of using bash for PKGBUILDs and the convenience of split PKGBUILDs, I really think this is going in the wrong direction. There is a difference between simplicity and laziness, and the trade-off of versatility and elegance is a considerable disadvantage of this direction, as previous discussions here have shown.
tar xOf /home/pkg/kernel26-firmware-2.6.32.3-1-x86_64.pkg.tar.gz .PKGINFO |grep pkgbase pkgbase = kernel26 grep -A1 BASE /var/lib/pacman/sync/core/kernel26-firmware-2.6.32.3-1/desc %BASE% kernel26
tar xOf /home/pkg/kernel26-firmware-2.6.32.3-1-x86_64.pkg.tar.gz .PKGINFO |grep pkgbase pkgbase = kernel26
grep -A1 BASE /var/lib/pacman/sync/core/kernel26-firmware-2.6.32.3-1/desc %BASE% kernel26
Thanks. Grabbing it from desc will suit my purpose.
participants (4)
-
Allan McRae
-
Pierre Schmitz
-
Xavier Chantry
-
Xyne