[MacPorts] #30144: kdepimlibs4: configure fails to find Nepomuk

[MacPorts]

#30144: kdepimlibs4: configure fails to find Nepomuk
--------------------------------------+-------------------------------------
  Reporter:  doug.mccomber@…          |       Owner:  macports-tickets@…                   
      Type:  defect                   |      Status:  reopened                             
  Priority:  Normal                   |   Milestone:                                       
 Component:  ports                    |     Version:  1.9.2                                
Resolution:                           |    Keywords:                                       
      Port:  kdepimlibs4 kdelibs4     |  
--------------------------------------+-------------------------------------

Comment(by macports@…):

 Replying to [comment:33 mk@…]:
 >
 > I am as annoyed as you are about the broken stuff. Right now not even
 dbus works for me. BUT...
 >
 > But I think you should know that enthusiasts contributing to MacPorts
 are spending their spare time to keep this alive. '''I have invested many
 hours during the last few days''' researching '''with other MacPorts
 committers''' to find a solution to this problem. And from what I know
 there is a cure in sight. At least locally I do have a working setup right
 now. snc (who you have ''successfully'' chased away from this issue's CC
 list with your '''INAPPROPRIATE RANTS''') has a first version of possible
 Portfile changes under review.
 >
 > I think it would be more helpful to direct your anger at the problem
 itself and try as well to find solutions.
 >
 > I am sorry, but I think that's the only way MacPorts can be kept alive.
 It needs testers, many of them, as well as their cooperation. And
 unfortunately KDE applications are not that frequently used...
 >
 > So, please, stay tuned and I am sure you'll soon have a working
 installation again.
 >
 > Concerning the build testing of ports triggered by port updates one can
 hope that future versions of MacPorts will have this functionality,
 hopefully centralized and automated.
 >
 > Patience is the key!

 I realize this is all a volunteer effort. I'm not criticizing people
 trying to help, but I am highly critical of tossing untested changes to
 the masses. As far as I can tell, a port version bump percolated up with
 other ports quickly changed to perhaps compile but be of no use. The
 proper solution is back-out the first change rather than break more ports
 on the way up with changes that will have to be undone once the base
 problem is fixed.

 This got me thinking about how other projects handle this and what the
 problem is with the way MacPorts handles it. Aside from committing
 untested changes, the problem in MacPorts is that the normal way a user
 keeps current is via rsync so they have the newest port tree snapshot.
 That's simple,. but makes it hard to go back to an earlier version on the
 ports. Compare this to two other familiar systems. Gentoo also uses rsync,
 but has the notion of port version exposed in the filename, as well as
 stable/unstable flags (per platform) in the equivalent of the portfile.
 This allows several versions of both stable and testing to be provided to
 the users at any given time, which means its easier for individuals to
 back down a version or two if needed but also jump ahead onto a testing
 version with the easy possibility to drop back to a stable version.
 FreeBSD is more similar to MacPorts from the portfile perspective, in that
 its ports tree only ever provides a single version of the equivalent to a
 portfile. However, their normally supported method of keeping up to date
 is cvs or svn (user choice) which allows a user to very easily revert a
 portion or the entirety of the ports tree to an earlier version should
 they have a problem. It is the fatal combination of single versions in the
 tree and updating with rsync to latest that makes it such a headache for a
 user.

 How to solve this going forward? First and foremost is simply more
 thorough testing. That will go a long way toward improving user
 experience. Second should be to put some thought into how best to
 restructure the portfiles system to allow users to drop back a version
 without the pain of manually fetching specific portfiles, which will then
 get stomped on during the next sync if that port is still broken in the
 tree.

-- 
Ticket URL: <https://trac.macports.org/ticket/30144#comment:34>
MacPorts <http://www.macports.org/>
Ports system for Mac OS