Notice: Undefined variable: name in /srv/http/vhosts/aur-dev.archlinux.org/public/web/lib/pkgfuncs.inc.php on line 248

Package Details: parmetis 4.0.3.p2-1

Git Clone URL: https://aur-dev.archlinux.org/parmetis.git (read-only)
Package Base: parmetis
Description: A parallel graph partitioning library
Upstream URL: http://glaros.dtc.umn.edu/gkhome/metis/parmetis/overview
Licenses: custom
Submitter: jedbrown
Maintainer: jedbrown
Last Packager: jedbrown
Votes: 22
Popularity: 0.033367
First Submitted: 2008-05-15 20:41
Last Updated: 2016-02-11 01:02

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

jedbrown commented on 2014-02-25 01:37

Thanks, Xyne. I made the changes you suggest.

Background in case people wonder about this package: I'm a PETSc developer. Upstream ParMETIS has some critical bugs that our users run into all the time, so we patched them and sent the patches upstream. Upstream doesn't really maintain ParMETIS and usually ignores patches sent by email or via forums. And yet these bugs are serious: memory errors and assertion failures. So we maintain patches. This is all in a legal gray zone due to the insane license, but George knows that we do it and has not objected (he's a reasonable person, but has mostly moved on and doesn't care about maintaining ParMETIS, but also doesn't want to lose control by switching to a decent open source license). Anyway, the p1 is not from "upstream", it is from me and other PETSc developers. You could think of it as if I (as AUR maintainer) were carrying those patches manually. This was my rationale before learning form you that 4.0.3.p1 is a valid version number, which is certainly not worse so I have updated.

We don't want to carry these patches, but to change that, the package will either need to be made open source or a viable competitor will have to step up. (Last I checked, PTScotch is too slow to be considered a "viable" alternative.)

jedbrown commented on 2014-02-25 01:15

Background: I'm a PETSc developer. Upstream ParMETIS has some critical bugs that our users run into all the time, so we patched them and sent the patches upstream. Upstream doesn't really maintain ParMETIS and usually ignores patches sent by email or via forums. And yet these bugs are serious: memory errors and assertion failures. So we maintain patches. This is all in a legal gray zone due to the insane license, but George knows that we do it and has not objected (he's a reasonable person, but has mostly moved on and doesn't care about maintaining ParMETIS, but also doesn't want to lose control by switching to a decent open source license). Anyway, the p1 is not from "upstream", it is from me and other PETSc developers. You can think of it as if I (as AUR maintainer) were carrying those patches manually.

We don't want to carry these patches, but to change that, the package will either need to be made open source or a viable competitor will have to step up. (Last I checked, PTScotch is too slow to be considered a "viable" alternative.)

Xyne commented on 2014-02-24 22:53

Addendum: by "subversion", I mean the "p1" suffix.

Xyne commented on 2014-02-24 22:52

Hi,

Following the changes to the metis package that I posted on the metis page, I have also updated the parmetis PKGBUILD to follow the same versioning scheme. You can find the source tarball in the same directory on my site: http://xyne.archlinux.ca/tmp/pkgbuilds/

If the upstream subversion number is completely incompatible with Pacman's versioning then some sort of conversion system should be devised. Multiple upstream versions should *not* map to a single Pacman version.

Whatever you decide to do, the changes should be consistent across metis, parmetis and parmetis-mpich.

Again, thanks for maintaining this.

Regards,
Xyne

jedbrown commented on 2013-01-03 14:18

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

Xyne commented on 2013-01-03 08:47

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.

Xyne commented on 2013-01-03 08:44

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!

Xyne commented on 2013-01-03 08:38

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!

myles commented on 2012-08-29 10:34

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

jedbrown commented on 2012-07-05 10:35

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.