Bug 537265

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.

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.

(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.

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.

(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".

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.

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.

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.

I think I might just close the ticket. It's a useful piece of software, but perhaps not worth the bother.