2013/1/9 Stuart Henderson <[email protected]>:
> 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.
Actually, no. libktorrent was split out of KTorrent upstream a while
ago as a separate distpackage, and corresponds to net/ktorrent-kde4
port only. And net/libktorrent does not conflict with net/ktorrent
except this nit:
* net/libktorrent installs ${PREFIX}/lib/libktorrent.so.X.Y;
* net/ktorrent installs ${PREFIX}/lib/libktorrent.so and
${PREFIX}/lib/libktorrent-${VERSION}.so (${VERSION} is KTorrent's
version itself).
I could rename libktorrent to libktorrent-kde4 to avoid confusion.
Even more, due to kdelibs-* conflict (they still could not be
installed at the same time) we could be sure that KDE3 and KDE4 apps
will not mix anyway for now. I do not want to manage conflicts of
KDE3<->KDE4 packages now because upstream packages gets split and
stuff in them gets moved here and there all over the time, forcing
re-doing un-conflict work eventually. Unconflicting KDE 3 and 4 is on
my TODO list, but not now.
> 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).
Of course.
> 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'm thinking on zapping it too, for the same reasons. It just helped in past.
> 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.
Thank you for the hint!
>> 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.
Yep, you're right.
>> 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.
Acknowledged.
>> 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 ;)
Hm-m-m, this path definitely should be investigated. I'm curious again
about adding name suffixes for KDE4-land packages, e.g.:
"digikam-kde4-2.9.0.tgz" or even "digikam-2.9.0-kde4.tgz" instead of
current "digikam-2.9.0.tgz"...
>> 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 :)
Acknowledged.
> I can help with getting this prepared (and importing) if I'm around..
Thank you. Hope this will not be needed, but who knows...
>> 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.
Fine.
--
WBR,
Vadim Zhukov
