[Kde-pim] Re: Check the version of kdepim-runtime?

Andreas Hartmetz ahartmetz at gmail.com
Wed Jan 12 17:48:15 GMT 2011


On Wednesday 12 January 2011 17:16:50 Volker Krause wrote:
> On Wednesday 12 January 2011 16:17:59 Andreas Hartmetz wrote:
> > Yesterday I discovered kdepim-runtime and that it might have caused many
> > of the problems I've had with KMail 2. It was so broken for me that I
> > had to go back to KMail 1.
> > What do you think about versioning kdepim-runtime (e.g. in the desktop
> > files of the agents) and increasing the version number after each major
> > bugfix or each bugfix release?
> > Then kdepim could check the version at runtime and notify unsuspecting
> > users of the problem, instead of failing silently. Other KDE apps also
> > version their plugins and have version dependencies.
> > 
> > We just had an IRC discussion about the issue and I don't buy that there
> > is not actually a problem. I don't read the README of everything I use,
> > I expect software to tell me in some way if an important dependency is
> > missing or outdated. Version numbers are not only for binary
> > compatibility.
> 
> So, what is the exact techinical problem we are trying to protect against
> here? Binary or protocol incompatible changes? Or distro/user failure to
> not update kdepim-runtime to a recent version that has new bugfixes? IIUC
> we are mainly talking about the latter one, right?
> 
Yes, I ran kdepim without installing kdepim-runtime, so I must have had some  
older agent versions.
On the one hand this is a stupid mistake you just shouldn't make. On the other 
hand, rereading the README of a project I've been using for years is too much 
to expect IMHO. I don't expect a change of dependencies in such a rather 
stealthy way.

> Versioning agents is probably not a bad idea in general, in case of an
> intentional BC/PC break. However, we are trying very hard to keep backward
> compatibility, so in case of an actual BIC/PIC problem, this would be
> unintentional and thus would likely not include the corresponding version
> number update. Versioning would thus not gain us anything, instead of
> updating the version number once noticed, we would rather fix the
> incompatibility.
> 
(see above). I do think that it makes sense to have a version number for 
agents in any case. If a user comes with a problem you want to know which 
version he's using. Versioning the agents is more reliable and less 
distribution-dependent than relying only on a package version.

> About the "someone forgot to update kdepim-runtime" usecase, this would end
> up being an ugly hack somewhere (I don't even know where, to avoid
> unecessary cross-dependencies between modules) that checks for a minimum
> version of an agent we know for sure to be in kdepim-runtime. We cannot
> just enforce a general minimum version for all agents with each update
> since agents are released outside of kdepim-runtime as well (playground,
> extragear, even non- KDE/non-FOSS). Even picking the agent that should be
> checked is non-trivial, if you look at e.g. how the KDE-maintained MeeGo
> packages split up kdepim- runtime.
> 
Ah, messy situation...
Depending on an Akonadi version from an agent should be easy enough since 
Akonadi versions are known. The other way around requires knowledge of the 
meaning of agent versions in kdepim, which is there in practice for agents 
from kdepim-runtime, but not in the general case.
To check the versions of agents from kdepim-runtime their desktop files could 
be used.

> Btw, is there a comparable check regarding kdebase-runtime somewhere? I'd
> guess we have the same problem there.
> 
> regards
> Volker
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list