Collaboration between the Community and the Kolab Repository [Was: Kontact Touch 4.8 Packages (conflict free installation)]

[Laszlo Papp]

Hey,

[...]
> Well I don't see that the Community repository is meant to be used on the
> device with aegis enabled.

It is; for instance in case Apps4MeeGo.

> To have a place to get your dependencies and then
> build your "large blob" that the ovi store wants, it makes sense. But I don't
> think it's meant to be a repository for Applications. So we can't seem to get
> a "conflict free" installation from that.

It helps with community activities, but as for Ovi: it is also a help
for getting your application bundled up. We have a common trick inside
the rules files of the existing KDE Harmattan applicationse (You can
checkout, for instance, kanagram-harmattan, khangman-harmattan or even
kalgebra-harmattan).

> I was also very frustrated last time i tried to use the OBS, i got wrong
> errormessages / errors that i could not reproduce in scratchbox, changes were
> intransparent, getting source packages is a hassle, etc. etc. thats apart
> from the performance or stability.
[...]

*Nodes*. I understand your frustration. Others also went through a
learning curve, but I think it is worth it. The problem with
scratchbox and other unpure environments: certain bugs are just not
revealed. I had this trouble few times. I sent my package to the
customer (built in scratchbox for instance), and it did not work as it
was intended to. I was wondering what can be the problem, and a pure
c-obs environment helped me towards to fix the bug.

> This is not a "Kolab" thing or so I personally was just ready to bite my table
> after fixing soprano in there and trying to get akonadi and another small
> package, that i forgot the name of, to build in there.

Yes, we were frustrated together in Berlin, too. At the KDE Harmattan
Sprint, that is. :) Still, I think it is not a value we should just
drop. I think, it also got a lot of improvement recently. I am
personally looking forward to see other targets, like raspberry,
blackberry, android and so forth, if possible. I mean it is fine
having scratchbox builds and temporary publishes (like I requested the
files.kde.org server for that), but we can still use the shared
knowledges and packages in a way.

On a side note: the kolab repository and way were also apparently
existing and done that way at Fremantle times as well. We have not had
C-Obs target for that platform though. I would have personally
expected some collaboration with the, partially "official", extra
repository. On the contrary, I must admit: I do not know the history
behind.

> Well the biggest issue I think is kdelibs and that you've based your packaging
> on (i think it was ubuntu) and not the existing Maemo 5 Packages from KDE. So
> now we use different names, have different dependencies build parameters etc.

Yes, but that is because I had the impression it is good to share the
knowledge with other well-experienced KDE packagers (ie. debian and
ubuntu community). Even at the momment, I am unsure if I started the
packaging in a too distinguished way. I think it is a good point we
can count with their work, and just merge into Harmattan. It really
helps a lot, especially since it was just almost me packaging the KDE
stack in the Community Repository (~huge manpower lack as usual :( ).

> Since the Maemo Packages from the komo branch in svn worked for KDEPIM for
> ~2Years now I'm also very reluctant to throw them away and start again with a
> different basis.

I can somewhat understand that, really. It is always a pain to drop a
huge work especially if certain things are already built on top of
that. :( It is a so unlucky situation. :/ KDE Pim depends on the
"Kolab" stack, and other packages like KDE Edu (kanagram, kalgebra,
blinken, khangman and so forth), KDE Games (gluon)..

> I know that you did not think of the komo packages when you started packaging
> KDE for harmattan but I think this is now the main problem, especially
> kdelibs, from just swapping out the packages.

I personally prefer the shared knowledge with Ubuntu/Debian as much as
possible since we do not have too many Harmattan specific issues apart
from some build flags and comments inside the install files.

>> There are also ideas to merge our debian KDE stack with the Plasma
>> Active rpm stack, and go together in our way helping each other... Let
>> us see what will come up to the reality.
> We should really try to get a repository for this. I don't see it as a
> practical way to grab/follow changes made to debian rules in an OBS.
> Something like we have for komo (even including rules for non-kde software):
> http://websvn.kde.org/branches/work/komo/packaging-master/
> But in a git repository, one branch for maemo5, maemo6 meego etc etc.
> This would easily allow us to review changes, see differences and follow the
> same direction.
> Currently this "pre VCS" way of grabbing each others debian.tar.gz's and
> comparing them is not working and I can't see it working in the future.

I might personally find the collabartion reasonable here as well,
whereas I am, admittedly, not an expert. I mean, there are pros and
cons. Many projects uses the same project for debian/rpm packages.. I
need to discuss the situation with the PA repository maintainer at the
Plasma Active 3 Sprint next week. I am unsure where we end up, but it
might be worth trying out. I am not that familiar with c-obs either,
but this comparing and tracking sound like a simply scriptable thing
(or even just "alias"). We would not like to lose the whole c-obs and
its goals because of this. I would rather prefer, if the aliasing or
automated script bother someone, to file a bug report. That said, I am
not that familiar with it either (since I only do packaging for need,
and not as a personal high-priority goal), thus there may already be
alternatives of achiving the simplified way.

> Once we work on the same packaging rules it really won't matter if one of us
> uses OBS or Treepackager or just builds on a local machine to actually create
> and publish the binaries.
> I think this would be the best way now to move forward and increase
> transparency and cooperation so that duplicated packaging won't happen again
> by accident.
>
> Do you agree with that?

The problem is not C-OBS, but a "background" issue as you said, so I
agree. Though, the collaboration can mostly only happen in my opinion
and according to my current understanding, if any of us is convinced
enough to drop the current way and rebuild the existing stack on top
of that with the other base. If I rebase my stack on top of the
"Kolab" repository; and I might need to forget to get any help from
Ubuntu and Debian KDE/Qt packagers; that said, it would be a pity in
my opinion. Admittedly, I have not studied the packaging in the
"Kolab" repository too closely, just mostly what you have showed up to
me at the KDE Harmattan Sprint.

Many lines written, but no real consequence on my side... Perhaps, we
could write up a list with pros/cons to simplify the decision, if
there is any need for such a thing to take place. I somewhat still
feel that, we are both reluctant enough to deal with this question too
much (we are basically mostly developers, and we do it, I think, to be
able to developer), and we might just perhaps continue the way as it
is. =)

Best Regards,
Laszlo Papp