On 2013/01/09 15:40, Vadim Zhukov wrote:
> I'm ready to start importing KDE 4 stuff, and plan to do this in the
> following order:
>
> 1. Import prerequisites, including non-SC stuff that was moved out of
> x11/kde4 in WIP: devel/automoc, productivity/akonadi, net/libktorrent
> and such. Also import fresh kde4.port.mk to allow testing them.
There's a conflict between net/ktorrent and the libktorrent port in
openbsd-wip.
If moving automoc outside of x11/kde4/automoc then dependent ports will
need to be adjusted; libqzeitgeist, polkit-qt4, ruby-qt4 (and the version
in x11/kde4/automoc removed).
I'm not a fan of using kdeversions.port.mk for ports outside of x11/kde4,
it slows people down if they have to do an urgent (e.g. security) update
as they have to work out where the definition is coming from (I ended up
grepping for it), also because cvs commits/updates are non-atomic, having
these in a totally different part of the tree increases the chance of
breakage if somebody updates a build machine while an update is being
committed.
I see you're using kdeversions to construct versions checks for ports
depending on a library e.g. in net/ktorrent-kde4/Makefile:
STEM->=${LIBKTORRENT_VERSION}:net/libktorrent
- I think this would probably be better using PKGSPEC instead, see
databases/db/v4/Makefile for an example of how it can be used.
> Do not
> link them to build, they are useless without KDE itself anyway. Can do
> this today.
I think I would prefer if these *were* linked to the build. They might
be useless for now, but this way they'll get build-tested at least, and
then linking the main part of kde4 to the build can be done in one place,
by just editing x11/Makefile.
> 2. Import the whole KDE SC 4.9.5 as x11/kde4. Can do this during a few
> days after verifing it packages fine. BTW, Rafael, what's your
> progress there?
Makes sense (unlinked) - cvs-wise this will be a bit fiddly so, when you
do this, make sure there is someone around who knows how to handle importing
with merge conflicts / removed files / etc.
> 3. Receive callback, fix bugs preventing from bulk builds. This should
> take probably 4-5 days more.
>
> 4. Import some more KDE 4 ports, depending on KDE 4: editors/calligra,
> editors/kile-kde4, graphics/digikam-kde4, net/ktorrent-kde4 etc. They
> probably can be linked to build immediately, except Digikam and
> Calligra maybe: those two take a lot of resources to compile (both
> disk and CPU); much less than LibreOffice, though. :) Note that
> kipi-plugins for KDE 4 is a subpackage of graphics/digikam-kde4.
disk/CPU isn't a reason not to link to the build, however approaching
an OpenBSD release with two versions of popular KDE-based apps and
no clear way to distinguish them when pkg_add asks "Ambiguous: choose
package for digikam" *is* a reason not to link them ;)
> Any objections or general thoughts? And a newbie question: what should
> be explicitly reviewed? Note that x11/kde4 will contain almost hundred
> of sub-ports. The most tricky part is kde4.port.mk.
Anyone reviewing it should have the whole thing available to look
through; x11/kde4 and new ports all in one big tar somewhere please
(outside of openbsd-wip, there is too much other stuff there to
isolate which parts are important for kde), and a diff for changes
to existing ports outside of x11/kde4 (one big diff generated from
/usr/ports so it can be applied in one go) - I don't think there
is any advantage to a diff for the x11/kde4 parts it will just be
too confusing :)
I can help with getting this prepared (and importing) if I'm around..
> Also, there is x11/kde4/kde-release-helper script in WIP tree. It is
> not used in builds but I rely on it a lot to speed up KDE update
> process. Should it be imported too?
Yes please.
