Re: [aur-general] the *scotch* issue

Dear Gordian Edenhofer, You are right :-) ( i hadn't yet discovered the real power of "provides") I finally adopted an orphan scotch and submitted the tarball. However, I hesitate to flag the fragmented *scotch* out-of-date / file deletion requests against them, as there might be good reasons for their fragmentation/obsolescence which i'm not aware of... I don't want to ruin anyone's workflow. That's why i wanted to first have this discussion with the packagers/maintainers. On Sat, Feb 14, 2015 at 7:51 PM, Gordian Edenhofer < gordian.edenhofer@gmail.com> wrote:

Dear George Eleftheriou,

as far as I understand your request, it could be solved a lot easier: First of all make use of the "provides" and "conflicts" variabel in your PKGBUILD ( https://wiki.archlinux.org/index.php/PKGBUILD#Package_relation_variables). Therefore there is no need to alter the already excisting and working PKGBUILDs of mumps and openfoam. Furthermore you can flag the other packages as out-of-date or even file a deletion request.

Best regards, Gordian Edenhofer

On Sat, Feb 14, 2015 at 6:53 PM, George Eleftheriou wrote:

...

=================================== to: mickele, myles, jedbrown as packagers/maintainers of the various AUR scotch flavours

cc: winstonwu9, gucong, kragacles, john_schaf, SMucalo as packagers / maintainers of various other packages depending on these AUR *scotch* ===================================

The other day, i needed to build ptscotch-openmpi and realized that it conflicts with scotch_esmumps5...

loading packages... resolving dependencies... looking for conflicting packages... :: ptscotch-openmpi and scotch_esmumps5 are in conflict. Remove scotch_esmumps5? [y/N] y error: failed to prepare transaction (could not satisfy dependencies) :: mumps: requires scotch_esmumps5

... but i couldn't remove scotch_esmumps5 since i have mumps installed on my system so... i did a quick search:

https://aur.archlinux.org/packages/?O=0&C=0&SeB=n&K=scotch&outdated=&SB=n&SO=a&PP=50

...

and realized that there are 5 (!) different versions of *scotch* in AUR. Then, i decided to do something about it.

1) Visited the upstream scotch website where i came across this

...

piece of information (copying from the Release Notes and Changelog of upstream 6.0.1):

"While this is technically a bugfix release, much has changed "under the hood" regarding repartitioning and (re)partitioning with fixed vertices. From now on, there is no separate "*_esmumps" version. The additional libraries for MUMPS can be generated by running "make esmumps" for the sequential libraries and "make ptesmumps" for the parallel libraries."

2) Took bits and pieces from the already existing PKGBUILDs, cleaned them up and made my own scotch PKGBUILD which grabs the latest sources (6.0.3) and encompasses all kinds of scotch that could ever be needed by AUR packages (serial + pt + esmumps + ptesmumps).

3) Uninstalled the scotch version I already had (scotch_esmumps5).

4) Installed my new "unified" scotch.

5) Built 2 AUR packages (openfoam and mumps) which depend on conflicting scotch versions by replacing the [pt]scotch[-openmpi][_esmumps5] dependency in their PKGBUILD with my new "unified" scotch. Just to test whether they compile or they give errors. Everything worked.

Suggestions/questions to all:

1) Would you mind checking my PKGBUILD (first attempt to make one but

interesting there

...

is nothing quite new inside anyway... it's based on the existing ones) for errors? Any improvements to propose?

2) Then, if everything is OK, do you agree in merging all AUR *scotch* into a single one in order to make life simpler?

3) the above also implies that the packages depending on *scotch* will have to change their dependencies' listings... I already attached the modified PKGBUILDS of openfoam and mumps, as samples.