Hi,
I'm bit confused .... I think the we need to arrange some IRC
discussion about these changes. I'm not against these changes, but a
bit confused.
On Fri, Oct 3, 2008 at 4:38 PM, Adriaan de Groot <groot at kde.org> wrote:
> 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.
>
It's very hard to maintain one repo for S10 and Nevada. Nevada is
changing a lot, so we need some more flexible buildsystem for that.
For S10 is our cvsdude is quite enough.
> [ade] (still rebuilding gettext multiple times and then comes Qt)
> _______________________________________________
> kde-discuss mailing list
> kde-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/kde-discuss
>
--
Lukas 'Luc' Oboril
IRC nickname: luc^ at freenode
When dealing with people, let us remember we are not dealing with
creatures of logic. We are dealing with creatures of emotions,
creatures bristling with prejudices and motivated by pride and vanity.
Dale Carnegie
