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 < [email protected]> 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 <[email protected]> > 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 > interesting > > 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 > 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. > > >
