Add to which package?

Oh, heavens. Sorry about that. The perl-sub-exporter package also provides perl-sub-exporter-util. Please add the provides info to perl-sub-exporter package.

I think adding pseudo-packages to provide versions of modules contained in the CPAN distribution is pointless. Especially since, in this case, the version of perl-sub-exporter-util would be exactly the same as perl-sub-exporter. Please just depend on perl-sub-exporter. If you have some special need of this provides, please explain your circumstances.

The provides is generally unnecessary and the only real advantage is to provide a search mechanism for modules, which is already available on CPAN search sites and need not be replicated in pacman. This also merges distribution and module names into the same namespace, with no means of distinction.

There are quite a few modules on the CPAN who require a module provided by a parent package (as in the case that prompted this request). This can get a little hairy and confusing when using an app, like cpan2aur, that doesn't appear to make sure the dependency exists as a package. cpan2aur seems to depend on makepkg finding and reporting this problem, which is fine.

Adding this information to the provides would appear to me to be a big advantage in making automated tools work better.

You intermingle the definition of CPAN modules and distributions. This is how this bad idea with the provides array was started in the first place. CPAN distributions are what define requirements upon a module. Modules do not define requirements upon modules. CPAN distributions are tarballs that contain files, which is why they correspond to Arch packages.

The requirements upon modules are cross referenced to requirements on the distributions which provide the module. For example, this is done by the cpan shell. When it finds it needs a newer version of the module, it looks up the distribution that provides said module, and installs the distribution. In the same vein, when a distribution is converted to a package the package author would hopefully cross reference the required module to the package name that provides it. When all is done, CPAN distributions correspond to Arch packages and vice versa. Module requirements are converted to package dependencies.

Automated tools have no problem cross referencing because both the cpan shell and cpan2aur perform this. An advantage a provides array... provides is that it allows packagers of perl distributions to not look up which distributions/packages contain the modules that fulfill their requirements. This is mostly a solution for human beings, which ironically might require generating all PKGBUILDs for perl dists using automated tools, as listing every contained module file in the provides array as a package would only add tedium for package authors.

Due to Arch's rolling release nature, it is usually not even necessary to find the version of the distribution which provides a given module version. Luckily modules named after their distribution almost always have the same version as the distribution which contains them.

You give no particulars and so it is difficult to direct a response but I hope this explains my reasoning to you. I'll be resigning soon and the next maintainer will most likely cheerfully accomodate you.

I understand your reasoning, and it makes sense, though I disagree with it. However, as you are the maintainer I respect your choice. :]

Hopefully you are retiring to better things rather than from annoying things. In either case, thank you for the time.