Bug 537265

Summary: Review Request: acovea - Analysis of compiler options via evolutionary algorithm
Product: [Fedora] Fedora Reporter: Bryan O'Sullivan <bos>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-package-review, notting, rc040203
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-23 00:59:23 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 201449    

Description Bryan O'Sullivan 2009-11-12 18:51:38 EST
Spec URL: http://www.serpentine.com/bos/files/acovea.spec
SRPM URL: http://www.serpentine.com/bos/files/acovea-5.1.1-1.fc11.src.rpm

Description:
ACOVEA (Analysis of Compiler Options via Evolutionary Algorithm)
implements a genetic algorithm to find the "best" options for
compiling programs with the GNU Compiler Collection (GCC) C and C++
compilers. "Best", in this context, is defined as those options that
produce the fastest executable program from a given source code.
Comment 1 Ralf Corsepius 2009-11-13 02:12:41 EST
Question: Is there a special reason why the packages this submission consists of can't be packaged as independent packages?

I would suggest you to reconsider your plan and to try submitting independent packages.
Comment 2 Bryan O'Sullivan 2009-11-13 02:16:44 EST
Those packages are not used by anything other than acovea, so I don't see the point of splitting them out. That's something I'd prefer to do if the need ever arises, which I strongly doubt will occur. The only component that anyone actually cares about is the runacovea executable.
Comment 3 Ralf Corsepius 2009-11-13 02:43:43 EST
(In reply to comment #2)
> Those packages are not used by anything other than acovea, so I don't see the
> point of splitting them out. That's something I'd prefer to do if the need ever
> arises, which I strongly doubt will occur. The only component that anyone
> actually cares about is the runacovea executable.  

I regret having to say so, but in this case, I strongly recommend to reject this submission, because packages which lump together independent libraries are non-maintainable in longer terms.
Comment 4 Bryan O'Sullivan 2009-11-13 11:50:04 EST
But they're *not* independent. They are shipped in separate tarballs, but libcoyotl is used by libevocosm, libacovea uses both libevocosm and libcoyotl, and nothing else in the entire world uses any of the three of them.

In fact, libcoyotl predates and overlaps heavily with the STL, and contains mostly code that it wouldn't make any sense for a modern C++ application to even consider using.

I'll redo the submission if I have to, but let me be clear that you are asking me to waste my time for no good reason.
Comment 5 Ralf Corsepius 2009-11-13 12:34:22 EST
(In reply to comment #4)
> But they're *not* independent. They are shipped in separate tarballs, 
That's exactly what qualifies them as independent.

> I'll redo the submission if I have to, but let me be clear that you are asking
> me to waste my time for no good reason.  
Pardon? I am intending to prevent you from running into a classical beginner-packager's mistake: "lumping together libs".
Comment 6 Jason Tibbitts 2010-11-13 16:17:39 EST
I'm just looking through these very old review requests.

In general, I believe the tests for whether separate upstream tarballs go together into one SRPM goes like this:

Are the libraries and main code all versioned together and released concurrently?  If you have updates to one library but not the other, or to the main package but not the libraries, then with separate packaging you'd just have to update the part that changed.  Code developed on separate schedules should go into separate packages.

Are the libraries and main code so interdependent that updating one would require updates to all of the others (and require buildsystem hackery to accomplish)?  Sometimes it's really just one project split up into a few tarballs.  Rebuilding such a thing is painful and it may be reasonable to bundle it together.

It also helps to know whether upstream considers them a unit.  (And if so, why do they split them?)

So, it would be good to have answers to those.
Comment 7 Bryan O'Sullivan 2010-11-22 13:47:12 EST
Jason, they are indeed all released together. Whether they were ever intended to be used separately isn't clear to me. As far as I can tell, upstream is moribund - there hasn't been a release in a long time.
Comment 8 Jason Tibbitts 2010-11-22 23:49:54 EST
Then what should be done with this ticket?  The less dead software in the distribution, the better as far as I'm concerned but if you're willing to step in and do the maintenance then that's that.  However, it is going to be tough to get information out of upstream if they've gone away.
Comment 9 Bryan O'Sullivan 2010-11-23 00:59:23 EST
I think I might just close the ticket. It's a useful piece of software, but perhaps not worth the bother.