We (KDE4-Solaris team) have been storing our efforts in CVSDude, an external
SVN hosting company. What is in there, and why?
- For each dependency <foo> for any part of KDE4, a directory FOO/
- Containing the extracted pristine source of some release of <foo>
- In there, a directory Solaris/
- Containing patches against the pristine sources
- Containing some build infrastructure scripts
- {patch,configure,build,install}.sh
- comments and readme if needed
- A SPECS/ directory with machinery for building packages out of the rest
- Contains no SPEC files
- Does contain "pre-spec" files which are processed by Respect.pl
- Assumes tarballs rolled out of the directories for <foo> are available
- A Build/ directory
- This was machinery used to build KDE SVN trunk
- Makefiles, cmake invocations
- Uncommitted patches against KDE SVN trunk
- A KDE/ directory
- With 4.1.0/ subdir
- Contains SPEC files that invoke versions of stuff from Build/
- Include relevant patches from Build/
- A CBE/ directory
- Containing a patched version of not-released CBE 1.7.0
So there's a lot of variegated stuff in there, and it's kind of inconsistent.
Some of that inconsistency is my fault, as I didn't understand SPEC files very
well when this got underway and inflicted that perl script on everyone.
This message is sort of by way of an apology.
At the insistence of Brian C. I looked at the GNOME / JDS SPEC files, and
found that they are actually remarkably clear and sophisticated. There's some
nastiness, of course, related to how you build each individual dependency or
part of GNOME, but that's to be expected. We have the exact same kind of stuff
in those Solaris/ directories, anyway.
So I sat down to take the excellent SPEC file scaffolding that Luc has made
around the tarballs that come from CVSDude and somehow make the Respect.pl
step superfluous. My goals here were:
- Write SPEC files so that *just* pkgtool is enough
- Be flexible in where sources come from
- Allow rolled-from-Dude tarballs
- Allow externally hosted (say the upstream tarballs) as well
- Check the accuracy of license statements in passing
- Learn to use Mercurial as well
By now I think I've pretty much succeeded in doing this for the dependency
tree of Qt. The pre-spec files we have created in SPECS/ are *almost*
perfectly usable SPEC files once you use the power of the pkgtool machinery.
So my porting strategy for .pspc to .spec is something like "remove three
lines of cruft, add one %include common.inc, add an accurate License: and
SUNW_Category: line and then expand the requires and buildrequires lines."
It's about 2 minutes per package and then a log wait while it downloads stuff
and compiles.
Using externally hosted packages from the original upstream is illuminating,
because it shows up loud and clear when the upstream has moved on to newer
versions; at the same time it's annoying because the sources you were
expecting no longer live there.
This is why I wanted to support *both* sources of tarballs; the construction
is such that we can roll tarballs from Dude and host them somewhere stable
(e.g. bionicmutton?).
A consequence of this work is:
- You can build everything without having a Dude checkout
- You don't need to live with all the weirdness of Respect.pl
- Builds become more straightforward, since you use the one build tool
I think the setup with Dude as it is works really well for the developers
working on packaging up the dependencies, works sort-of for developers who
want to work on KDE4 on top of a stable base, but is overly convoluted for
people who are primarily interested in deploying KDE4 or doing runtime testing
(frankly, I'd still recommend doing the latter *before* deployment).
My intentions at this point are vague. I'd like to put this stuff up
somewhere, but I see it as something separate from the work done in Dude. It
might be good for public perception (for such public as there is) to have it
in a repo associated with the KDE project on opensolaris.org.
[ade] (still rebuilding gettext multiple times and then comes Qt)
