trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: February 2014

Re: [trinity-devel] Commit c926c513 (amarok) caused a conflict between packages

From: Michele Calgaro <michele.calgaro@...>
Date: Sun, 16 Feb 2014 09:30:44 +0000 (GMT)
> I have opened the bug:
> http://bugs.pearsoncomputing.net/show_bug.cgi?id=1937
Good idea and well thought :)

> There are still those building from the tree that use the qt3/3.5.13 codebase. All of the
> directories applicable to that build knetworkmanager8, etc. should remain in the tree.
I am not the one deciding what goes and what stays, just expressing my opinion (and even less I want to start a "holy war" on this subject).
Those building on qt3/3.5.13 have all my respect, but to build 3.5.13 you either 1) already have the code for 3.5.13 locally or 2) you have checkout a 3.5.13 branch/tag or equivalent list of commits.
What is in the main trunk at the moment is very different from 3.5.13. As a matter of fact, even trying to build R14 from the repository of one year ago requires considerable manual effort to get everything to build properly (being there while investigating bug 1825).

IMO, the trunk should reflect what is needed now, for R14. For past versions, there is git.
Packages required for branch x.y.z should be in the x.y.z branch; packages that are not, should not.  As simple as that.
If package abc is required for branch x1.y1.z1 but not x2.y2.z2, package abc should be in the branch x1.y1.z1 and *not* in the branch x2.y2.z2. The same applies to the trunk.

If I want to build version x3.y7.z5, I checkout version x3.y7.z5 and git takes care of doing all the dirty work to give me the sources of that version.

Following your logic for knetworkmanager8, then we should also keep the original version of all modules that have been renamed (kde -> tde) because they are needed in 3.5.13. The trunk would quickly "explode" :)

Cheers
  Michele