On Wednesday 25 March 2009 01:58:00 Ben Taylor wrote:
> On Tue, Mar 24, 2009 at 6:03 PM, Petri Kunnari
> <petri.j.kunnari at gmail.com> wrote:
> > Well if it really does require plenty of rework then it is not maybe not
> > worth of redo everything.
> > But if it is only edit spec-files to match requirements i could take a
> > look.
>
> The KDE4 may be pure spec, but everything needed to actually build
> is a combination of sources from our SVN repo at cvsdude.com which
> is where the major "dependencies" tool chain using Studio 12 as the
> compiler work is done, and the spec files that use those customizations
> (it's not pure spec for those packages)
I'm not sure I follow here. Each one of the specfiles is exactly that: a
specfile. A specfile lists some meta-information about a package (for instance
which source tarballs are needed) and includes a bunch of scriptlets that
perform the actual build (by invoking other tools within a build environment).
At some point in the past we introduced the terms 'pure specfile' and 'other
specfile' to distinguish between:
- a 'other specfile' has scriptlets which invoke other scripts which are part
of the downloaded sources. These scripts are the tarred up Solaris/
directories which live in Dude. These are called 'other' (or 'impure') because
of the additional indirection via the external scripts. You could merge the
contents of each Solaris/ directory from Dude into the specfiles yielding:
- a pure specfile has all the build functionality visible in the scriptlets
themselves. This is how most specfiles work: they just have one download
tarball (the pristine upstream source) and then list a bunch of patches and
have scriptlets that apply the patches, call configure, etc.
Both kinds work; probably both kinds are usable within SourceJuicer, although
you might argue that the extra indirection (and execution of scripts from
third parties) is not a good idea and doesn't help in review. Since no-one has
tried this out (except maybe Shawn) it's a little too early to make statements
about the amount of effort involved.
There *is* a non-trivial effort, though: there are naming, licensing and
dependencies requirements which need to be met which the specfiles we have do
not satisfy -- not to mention that expressing the dependencies in OSOL is
different from the same dependencies in nv or s10 because packages have
changed names.
> > Which revision is recommended to take as startpoint ?
>
> Help verify KDE-4.1.4 before going any further, if you really
> want to help. We're building on S10, Nevada, and OSOL.
Just grab what's current, make sure it builds for you, adjust for the
requirements of juicer, submit. I think the naming thing is going to be the
most work, if only because it means dropping the FOSS* prefixes and setting up
default-depend to have depend_* definitions for everything. (One simple case
is renaming FOSShier to hier-kde4-deps and KDEhier to hier-kde4; FOSSgiflib
becomes giflib, which has a bigger impact.)
--
Adriaan de Groot - KDE Quality Team, KDE-Solaris
- http://www.englishbreakfastnetwork.org/
- http://solaris.kde.org/
