[pacman-dev] Matching split packages to PKGBUILDs

[Allan McRae]

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