Arch Linux User Repository

@Xyne Parmetis really does depend on metis (as of version 4). I've cleaned up the PKGBUILD based on your suggestions.

Hi,

I have uploaded a PKGBUILD with some corrections:
* pkgname changed from an array to a string
* empty variables removed
* quoted $srcdir and $pkgdir variables to prevent word expansion
* removed "metis" from dependencies (a package should never depend on and provide the same package)
* added "metis" to the conflicts array, assuming that it really does provide metis

If the last two points are wrong, remove "metis" from the provides and conflicts array. If it really does depend on metis, add it back to the depends array.

You can the PKGBUILD: http://xyne.archlinux.ca/tmp/parmetis/
There's no need to bump the $pkgrel because the resulting package is identical.

Thanks for maintaining this!


p.s. Sorry if you received this message multiple times via email.

Hi,

I have uploaded a PKGBUILD with some corrections:
* pkgname changed from an array to a string
* empty variables removed
* quoted $srcdir and $pkgdir variables to prevent word expansion

You can get it here: http://xyne.archlinux.ca/tmp/parmetis/
There's no need to bump the $pkgrel because the resulting package is identical.

Thanks for maintaining this!

Hi,

You should not include empty arrays and variables in the PKGBUILD.External variables ($srcdir, $pkgdir") should also be quoted to avoid unwanted word expansion.

I have uploaded an updated PKGBUILD: http://xyne.archlinux.ca/tmp/parmetis/
There's no need to bump the $pkgrel because the resulting package is the same.

Thanks for maintaining this!

aurup parsed html rather than rpc, and so fell foul of a format change not long ago, it is recommended to use burp to upload packages now

I had uploaded it using aurup, but strangely, the result wasn't visible here. I tried again with aurup, which completed successfully again, but still didn't show up here, so I uploaded manually.

I understand that there is a consistency issue, but we (somewhat necessarily now) maintain the PKGBUILDs for metis and parmetis together. Feel free to email George suggestions about dependencies and packaging.

i'm sorry but i'm not talking about aesthetics here.
if metis is built separately and parmetis builds it inside and does not use the external one, configuration issues can arise easily.
i agree that this issue should be addressed by the parmetis build tools (the 4.0 version switch has not improved things, i'm very sorry to say).
will you update the PKGBUILD in order to list metis as a "depends" and not as a "provides"?

Parmetis "make install" does not install Metis. We have been using both with this dependency in PETSc for more than half a year (many users on different platforms) and this approach has been working fine. Talk to George if you think installation should be done differently. (I do, but he has not been responsive about applying patches for real portability issue, so it hasn't seemed worthwhile to press on more aesthetic issues.)

i believe metis is built inside parmetis, the problem is that it not installed along with it.
adding metis as an external dependency can be dangerous if the configuration is not consistent.

Parmetis depends on Metis since the latest release. I just updated the package to add this dependency.