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
