Tellico installation wants to remove kmail5

English Install/Boot/Login
1

During testing Leap42.2 with KDE I wanted to install tellico.

Telico is a Collection application, where you can store information about yopur collections. In this case I use it for years to store information about my musical CD collection. It is one of the first packajes I install right after the system installation:

nieuw:~ # zypper in tellico
Loading repository data...                                                                                                                                                       
Reading installed packages...                                                                                                                                                    
                                                                                                                                                                                 
Resolving package dependencies...                                                                                                                                                
                                                                                                                                                                                 
Problem: tellico-2.3.11-1.14.x86_64 requires kdepim4-runtime, but this requirement cannot be provided                                                                            
  uninstallable providers: kdepim4-runtime-4.14.10-4.6.x86_64[download.opensuse.org-oss]                                                                                         
 Solution 1: Following actions will be done:                                                                                                                                     
  deinstallation of kdepim-runtime-16.08.2-1.1.x86_64                                                                                                                            
  deinstallation of kdepim-16.08.2-1.1.x86_64                                                                                                                                    
  deinstallation of kmail5-16.08.2-1.1.x86_64                                                                                                                                    
  deinstallation of korganizer5-16.08.2-1.1.x86_64                                                                                                                               
  deinstallation of kaddressbook5-16.08.2-1.1.x86_64                                                                                                                             
  deinstallation of akonadi_resources-16.08.2-1.1.x86_64                                                                                                                         
  deinstallation of akonadi-server-16.08.2-2.1.x86_64                                                                                                                            
 Solution 2: do not install tellico-2.3.11-1.14.x86_64                                                                                                                           
 Solution 3: break tellico-2.3.11-1.14.x86_64 by ignoring some of its dependencies                                                                                               
                                                                                                                                                                                 
Choose from above solutions by number or cancel [1/2/3/c] (c):                                                                                                                   
nieuw:~ #

It is a bit beyond my understanding what the connection is between Kmail and this application. AFAIK tellico does not even use a database, but stores it’s data in his own way in one large file (well, by definition that is a database, but not one of the databases that are in common use).

I am interested if anybody can shed light on this. Is it an error in (the build of) tellico? Should I file a bug report (or contact the developer, I once did and had a good understanding with him)?

2

Hi Henk!

From the output that you posted I guess the problem is

tellico-2.3.11-1.14.x86_64 requires kdepim4-runtime

In my 42.2, kdepim is installed, but it will be kdepim5, because the Yast->Software Management offers the package kdepim4, which is not installed.

kmail5 will depend on kdepim5, and if kedpim5 is deleted, kmail5 can’t stay.

The problem to me seems to be that there isn’t a version of tellico yet for the new KDE that runs under 42.2.

Mike

3

Reading the tellico project page
http://tellico-project.org/

It looks like the version in the standard 42.2 repos which you’re trying to install (v2.3) is a kde4 (older) framework app, so is incompatible with your currently installed Plasma 5.

I found the version you need (beware, as the Tellico Project page says, it’s still in Beta) in the KDE:Extras repo, you can add that repo by running the following in an elevated console (eg logged in as root or use sudo)

zypper ar -f http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Leap_42.2/ && zypper --gpg-auto-import-keys ref

After the above, now you can search for, and install tellico and you should install v3.0 which should install without removing your kmail and other dependencies.

TSU

4

Thanks both of you.

Of course I noticed that tellico wanting kdepim4 stuff is the crux.

But I indeed forgot to consult the tellico web page.

I was a bit flabbergasted that tellico needed such a thing as kdepim. IMHO it always was desktop agnostic. I am a bit worried that this basically simple program (a GUI that feeds in and out of a file) now depends on a certain desktop application suite (might not be the one you use). And the result of this new dependency shows: it has to keep pace with that desktop, like it or not.

BTW, the way I found out about this was a bit a different story. During system installation, I normally remove some packages I do not need (and do not want to be on my system for one moment) from and add some other packages I always need to the list of software to be installed. Thus I added tellico and did the installation. Later I tried out the KDE desktop and could not find Kmail in the KDE main menu ?!?!?!?! Real surprise. Adding Kmail after this, I found two Kmails (rather confusing for a beginner), of which kmail5 wanted to remove tellico. Thus I reinstalled without adding tellico, trying to add it later, as I thought that would be the more normal case to present here.

5

Without knowing exactly how tellico works,

IMO it’s a reasonable assumption that tellico has a fairly close relationship and therefor dependencies of the types of items that are being collected and where they come from.

Since the mail app is a dependency,
I’d speculate that tellico can create collections that include mail data (messages, maybe even message attachments) so needs to be able to “talk” to supported mail apps.

In fact, if I were designing an app like how tellico is described, tellico only creates metada that connects to various objects which can be members of a collection. The actual object data remains where it is, no copies are made. And, so tellico uses an API (Application Programming Interface) which is specific to other applications that store the actual objects to access those objects, particularly in the case of mail which might be stored many different ways and may not be directly accessible by an outside app.

TSU

6

For me, and it could be that Tellico nowadays can also act on objects inside the system, it is just a management system for collections. Collection in this case being e.g. stamps, books, coins, CDs, wine, you name it. Those objects are nomally in drawers, paper albums, cellars. But when you are a genuine collector you want to administer what you have. And nowadays you do not write that all down in a paper catalogue of some sort, but in one or more files. And the you want something that is better then some pen and paper list, but something you can browse through on several expects (show me all the years of my wines sorted).

Tellico is such an interface. You can decide yourself which properties you want for your collection, but it comes with basic sets for some popular collection types to start from. E.g. for our world music collection I have: Artist, Musical genre, instrument, label (publisher), hardware (CD, DVD, …), year.
For every Album, I can have more artists when needed and more instruments, etc. Thus when I want to know on which Albums artist Aaa performs, I choose Artists as the main column, go down to Aaa, see there Aaa (4), meaning four albums, open it and see those four albun titles, click on them to see all the details.

For each album, I can also enter the list of contents, and more.

Just to give you an idea.

The way I use tellico, no other application inside the same (or any other computer in my house) can store, copy, or do anything to those CDs in our drawer in the living room. Thus tellico is not an API to such a a not existing application.

For me it is a GUI application between me and a database. I could have build it myself using LAMP (i did a similar thing for a book collection and for my colour slides). But is was already there, answering my needs. It has some strange GUI effects, but I am used to them. I only was amazed that it did not use something like MySQL for it’s storage, but one file with a structure of the tellico designer’s own invention (read compltely into memory on tellico’s start, changed and written back completley when asked and on program finish). I once asked him why. His answer was that he wasn’t good enough in SQL, but that he would be happy if someone could convert. My own SQL knowledge being rather small, i did not step in.

BTW, that conflicting dependency is not direct;y with Kmail (and tellico has no interface to mail imho), the conflict is a deeper lying package that both use. Both need a different version of it and both versions can not co-exist. kdepim4-runtime vs. the KDE 5 version of it. Why tellico uses a kdepim runtime library I have no real idea, but it is not mail.

7

This is not a new dependency at all. tellico requires kdepim4 since at least 2010.
See the tellico 2.2 release notes:

Tellico 2.2 ReleasedSubmitted by Robby on Sun, 02/14/2010 - 16:07
Release

Tellico version 2.2 is available.

Features
Enabled KOrganizer integration for adding loans to calendar (kdepimlibs required).
Enabled KAddressBook integration for adding borrowers from the address book (kdepimlibs required).
…

And kdepim is not at all related to the desktop. So no, it does not have to “keep pace with that desktop”.
kdepim5 was even only released 1 year after Plasma5…

Anyway, as has been mentioned already, tellico 3.0 has been released recently (unfortunately too late for the 42.2 release), which is ported to KDE Frameworks5.
http://tellico-project.org/tellico-30-released
You can get it from KDE:Extra, and it won’t require you to install kdepim4-runtime and remove kmail5.
And actually it is missing kdepim integration completely currently AFAIK, there’s even a bug report about that.

The other option is to switch back to kdepim4, which is still included in 42.2.
Actually if you upgraded from previous versions, you wouldn’t have had that problem because you’d still have kdepim4 installed.
Only a fresh installation contains kdepim5.

8

That is all nice stories and so about all sorts of versions of all kinds of packages. but the main problem I see is that I do a fresh install of a current version of a distribution. That I then add one of the applications available on the “official” repositories that “are” that distribution and that it fails to install (except when I push it and it will then cripple the current working environment). I do not think that the average user that installs openSUSE Leap 42.2 can be expected to understand much about the difference between KDE, it’s PIM, their history and dependencies.

And I do not understand much from:

Actually if you upgraded from previous versions, you wouldn’t have had that problem because you’d still have kdepim4 installed.
Only a fresh installation contains kdepim5.

This confuses me and several questions come to my mind struggling to be the first to be answered. Like;

  • are you blaming me installing openSUSE Leap 42.2 instead of upgrading from something earlier?
  • do people doing some form of upgrade instead of a fresh installation end up with a different system that runs different software?
  • why is KDE PIM 5 in the the openSUSE Leap 42.2 distribution when one is not supposed to install that distribution fresh, but to upgrade from something that then has to be installed first with the result that KDE PIM 4 is installed instead?

Your remark is also suggesting that I do have now an openSUSE version with KDE PIM 4, which is not the case. I do run openSUSE 31.1 with KDE PIM 3.5. Still stuck because of show stopping features los in KDE PIM.

9

And I use Tellico sinds about 2006. Of course I never look, let alone study, which dependencies packages have. I use the product. And it never came to my mind (and I repeated again and again above: from my usage of the product) that managing my CD collection could have anything to do with KDE PIM or the like. I only know it as being stand alone, even without usinmg a open source database for it’s database. Thus I was flabbergasted by thus usage, which now exposes itself as a software package dependency.

It only shows that even the most simple program you use might have cross consequences with, well almost everything you would never expect.

10

It is mentioned in the release notes though that we ship both kdepim4 and kdepim5 in Leap 42.2, and that some applications require kdepim4.

are you blaming me installing openSUSE Leap 42.2 instead of upgrading from something earlier?

I am not “blaming” you, I just wanted to point out a difference between upgrade and fresh install here.

do people doing some form of upgrade instead of a fresh installation end up with a different system that runs different software?

Of course, and that’s not a new thing either.
If you upgrade, the system will try to keep what is currently installed (and update it).
Whereas a new installation will select a default set of packages.

why is KDE PIM 5 in the the openSUSE Leap 42.2 distribution when one is not supposed to install that distribution fresh

I never wrote that “one is not supposed to install that distribution fresh”.

KDEPIM5 is in the distribution, because it is the current and only maintained version.
KDEPIM4 is mainly there for compatibility, and to prevent “surprises” on upgrades.

A fresh (KDE) installation will install KDEPIM5, because kdepim4 was dropped upstream one and a half years ago and is basically unmaintained.
It has been decided to keep kdepim4 on upgrades though, for now.

In 42.3, kdepim4 will not be shipped at all any more, although the original plan was to drop it in 42.2 already.

Your remark is also suggesting that I do have now an openSUSE version with KDE PIM 4, which is not the case.

Tellico (2.x at least) does require kdepim4-runtime, so if you installed tellico, you will have kdepim4-runtime installed as well.
That doesn’t mean that you have to install/use kmail4 or the other KDEPIM4 applications.

The KDE3 packages are co-installable in general, because they put their files to /opt/kde3/ instead of /usr/ (for historical reasons).
So it is also possible to install kdepim4/kdepim4-runtime and kdepim3 at the same time.

I do run openSUSE 31.1 with KDE PIM 3.5.

I thought this was about 42.2? :wink:

Still stuck because of show stopping features los in KDE PIM.

Not sure what you mean with that.
I don’t think there is any “feature loss” in kdepim4 or kdepim5 (although some applications have been removed in the latter, knode and ktimetracker in particular), actually features have been added.
But that’s a different topic anyway.

11

Yes. That’s the case. And planned to be so.

12

What is the joy of that? Making support from here easier? Do we need an extra entry in the the drop down menu to make a difference between “LEAP 42.2 upgraded from earlier version” and “LEAP 42.2 fresh install” so people here know what thread starters have?

And what are people supposed to do? First test a fresh install to see if everything is OK on e.g. a test or virtual system and then being satisfied upgrade their production systems to end up with something completely different?

This is rather beyond my understanding :(. But I have no doubt it is just me.

13

PS: Feel free to file a bug report at http://bugzilla.opensuse.org/ about that “problem”.

Personally I see these ways to solve it currently:

  • build tellico without KDEPIM support in 42.2 (I think that’s possible, but would mean that the features are gone for everybody)
  • release tellico 3.0 as update for 42.2
  • change the dependencies to not require kdepim4-runtime. I suppose it will work without it in general (would need to check though), except those functions that use KDEPIM will not work unless kdepim4 is installed and Akonadi4 is running. kmymoney was a similar case, and we did exactly that there (in 42.1 already).
14

Sorry, I don’t get you.
People will have different software installed anyway.

There’s already a difference on fresh installations depending whether you select GNOME, KDE, or whatever else during installation.
Not to mention that people add/remove random packages.

And upgraded systems likely diverge even more, no need to make a fuss about kdepim4/kdepim5 now.

And what are people supposed to do? First test a fresh install to see if everything is OK on e.g. a test or virtual system and then being satisfied upgrade their production systems to end up with something completely different?

Well, if you want to test whether it will work on your production systems, you should do exactly the same in the test as you would do on your production systems I’d say.
I.e. install fresh in both cases, or copy your production system for the test and do an upgrade.

Btw, nobody reported this tellico dependency “problem” during the beta and RC phases, otherwise this might have been worked-arounded already…

15

I don’t think the KDE devs and openSUSE packagers have things like this in mind. The idea IIRC was to make upgrading easier for users already on Leap. Since Leap 42.1 still had kdepim4 and given Leap’s supposed to be LTS …

And what are people supposed to do? First test a fresh install to see if everything is OK on e.g. a test or virtual system and then being satisfied upgrade their production systems to end up with something completely different?

I think we agree that if an upgrade path is to be taken, we have to test the upgrade path, not a fresh install .

This is rather beyond my understanding :(. But I have no doubt it is just me.

We sort of discussed this matter/your issues on Saturday. Like I said there: things change. At the time of KDE3->KDE4 I too was confronted with the loss of Categories in kAddressbook. I took the opporunity to clean up the addresses a bit and use Groups ever since. Checked the wife’s kAddressbooks and she has almost all addresses in one or more groups, and uses this feature like you use Categories. Again IIRC since it’s been quite a long time, she found back most of her Categories as Groups. And, you can still add a Vcard folder to kAddressbook, f.e. on an NFS share to share the addressbook with others. IMHO you’ll be confronted with more and more issues by sticking to old software to avoid changes.

16

Please do not mix the case of the tellico incompatibility with the policy that is revealed by it.
You can consider the tellico case as closed. I will circumvent it someway. As I thought it would be possible from the beginning, but I consider these forums also as a place to signal problems (hopefully with their solutions) to others.

I also want to stop the discussion about: “you will get KDE PIM 4 or 5 according to some algorithm”. Those who have read this will come to their own conclusions. The only thing that is still not answered is the why. I asked: what is the joy? No answer. The best we got thus far is: “planned to be so”.

17

It is simple

Upgrade your old stuff that is not replaced is kept

New install only the new stuff gets installed.

No fancy algorithm involved. :wink:

No one noticed during testing that there was a problem. Did you test it during the betas??

18

Hm?
This thread is (was) about “Tellico installation wants to remove kmail5”.

I’m not sure what you mean with “what it revealed by it” though.
That kdepim4 and kdepim5 are not installable at the same time? This is mentioned in the release notes as I wrote.

Or that users can have different packages/applications installed?
Well, big surprise there.
And you yourself stated that you are still using kdepim3 (which isn’t installed by default since years). How would that fit into the distribution selection here in the forums? :wink:

The only way to solve this would be to not offer any choice during installation (GNOME, KDE, …), install a uniform set of packages on every system (regardless whether you install fresh or upgrade) and lock down the system to prevent adding/removing packages/applications at all.
Would definitely ease support significantly (both for the distribution and here in the forums).
But this would not be something then that I (and a lot more users IMHO, including you) would like to use.

You can consider the tellico case as closed. I will circumvent irt someway. Ass I though it would be possible from the beginning, but I consider these forums also as a place to signal problems (hopefully with their solutions) to others.

But without a bug report, nothing will change (in 42.2 at least).

This is “fixed” in KDE:Extra and Tumbleweed (and will be in 42.3 also) by the upgrade to Tellico 3.0, but for 42.2 we’ll need a bug report.
Btw, this problem only did not occur in 42.1, because that still installed kdepim4 by default (on a fresh installation too).
kdepim5 was already included as well though, and if the user switched to it manually, the same conflict would happen when trying to install tellico 2.x.
As I said, we did make a change to kmymoney to fix a similar issue, because somebody filed a bug report.

I also want to stop the discussion about: “you will get KDE PIM 4 or 5 according to some algorithm”. Those who have read this will come to their own conclusions. The only thing that is still not answered is the why. I asked: what is the joy? No answer. The best we got thus far is: “planned to be so”.

It’s not “some algorithm”. It’s just that kdepim4 will not be replaced by kdepim5 if it is installed.

And I did shortly mention why:
E.g. to avoid/minimize “surprises” on upgrades.
Some (two) applications have been dropped in kdepim5.

Also, there were reported problems with kdepim5 in Beta1 for which the cause couldn’t be found, I think that was actually the main reason to decide to resurrect kdepim4 in Beta2 (and not replace it on upgrades).

19

That is exactly what I am doing now.

First phase is installing an openSUSE Leap 42.2 (on new hardware), to see what the newest supported software can offer me. In other words, how I (and my users) can use this software to satisfy their needs as good as possible. Amongst other things, what are these groups and how to use them, do shared vCard directories work now and when not what is the alternative. And many, many more things. Unburdened by what was earlier. Next phase will be to integrate old data (home directories, LAMP database, CGIs, web pages) in such a new system, forking the reality. Last phase will be replacing the old software by the new one on the production systems. Is that a very wrong way to go?

During this I found out I had no Kmail at all. You now know why. While I assume the tellico thing being minor, I nevertheless thought it would be an interesting case for others (or am I the only tellico user around?).

As a side show to the tellico problem we now have the question to what is the way to go. KDE PIM 4 or 5?

20

The why and the joy: After SUSE released it’s code base to openSUSE, which led to the changes we now see as Leap - an LTS version - and Tumbleweed - our rolling release- we had to face a couple of cases re. updating/upgrading. When Leap 42.1 came out, kdepim5 wasn’t considered ready for being the default. And now it is. Given Leap’s LTS idea this meant we have to ship kdepim4 for those that started with Leap 42.1, But, given current development at kde.org, we cannot leave out kdepim5 for those that install Leap 42.2 freshly ( can you imagine the storm if we wouldn’t ). AFAIK based on this reasoning Leap 42.3 will also contain both kdepim4 and kdepim5. If we wouldn’t do it like this, IMHO we wouldn’t have Leap as an LTS, but rather an outdated version. This way we provide an upgrade path and a relatively up to date release.