Bug 1575

TDE is not binary compatible with KDE 3.5.10.  As a result, adding a Provides line to the deb file is not likely to work at all; even in those cases where it still appears to work, future changes to TDE will likely render this method inoperable.

Instead of attempting to use the old unsupported binary packages mentioned, you should file Request for Packaging bug reports on this bugtracker, requesting that those packages be rebuilt against the latest versions of the TDE core libraries.  This will ensure that those packages continue to be available into the future.

Then, you should increase second version number (f.ex. kdelibs4c3).

(In reply to comment #2)
> Then, you should increase second version number (f.ex. kdelibs4c3).

This is a valid point.  We now use tdelibs, and the API/ABI have both changed significantly, so I suspect the sonames in tdelibs should be bumped to 5.0 and therefore the package name itself should be changed to tdelibs5.

Raising to BLOCKER to make sure that this gets in to R14.

I think, in case of rebranding you should change version to 1.0 or at least continue 4 major. Version 5 is not very good idea, because it makes confusion with kdelibs 5.

Anyway, I suspect that core architecture was not significantly changed. Are the API changes documented somewhere? Do you plan to merge API of kdelibs 5 (to achieve compatibility with their apps)?

Is this report something one of us "junior" hackers can resolve? What is needed?

Do we want to bump to 5.0 or as suggested, 1.0?

(In reply to comment #5)
> Is this report something one of us "junior" hackers can resolve? What is
> needed?
> 
> Do we want to bump to 5.0 or as suggested, 1.0?

It is Bad Practice to decrement the version number.  Either we go to 5.0 or 14.0.

Thoughts?

Tim

Bad Practice. Okay. :-)

14.0 then.

Is this something someone like me can do (I need instructions), so you can focus on the challenging bugs?

As no one has raised any concerns on this report regarding a version jump to 14.0.0, I have committed this change to GIT in hashes cb17faa (tdelibs) and a3fed09 (tde-packaging).

Someone should probably double-check my work as this is the first time I have done this sort of thing. :-)

I think that would be appropriate for Debian / Ubuntu packages also rename tdelibs4-trinity-dev and tdelibs4-trinity-doc => update 4 to 14.

What do you think?

Note: Because this change will require a rebuild almost the entire git tree, it would be good to push proposed patch for common admin module, because it also causes rebuild almost the entire tree - see:

http://trinity-devel.pearsoncomputing.net/?0::11395

I have to push the patch quickly, for this reason?

(In reply to comment #10)
> Note: Because this change will require a rebuild almost the entire git tree, it
> would be good to push proposed patch for common admin module, because it also
> causes rebuild almost the entire tree - see:
> 
> http://trinity-devel.pearsoncomputing.net/?0::11395
> 
> I have to push the patch quickly, for this reason?

Yes, go ahead and rename tdelibs4-trinity-dev and tdelibs4-trinity-doc after pushing the referenced admin/ module patch.  To avoid problems during this process, I have deactivated the autobuild system until all changes have propagated fully.

What should we watch for when we rebuild after applying these patches?

(In reply to comment #12)
> What should we watch for when we rebuild after applying these patches?

The tdelibs4 rename only affects Debian and Ubuntu.  As far as building from source goes, the only changes would be that the various tdelibs library files will be installed with a .14.0.0 suffix instead of a 4.2.0 suffix.  This change will largely be invisible due to the fact that each library also installs with two symlinks pointing to the .14.0.0-suffixed file; one symlinks as <libraryfilename>.14 and the other symlinks as <libraryfilename>.

Ok. I ran a build set with the sources updated from last night and I see the renamed lib files. No build problems and no usability problems thus far.

I can confirm - the largest patch applies to Debian / Ubuntu trees in tde-packaging. I just checking patch, commit will be for a while.

Update in admin module does not have a direct connection with this renaming of the library suffix. The only thing that both are done simultaneously, because both leads to rebuild the entire GIT tree.

Both finished!

It is perfect as GIT deal with parallel processing update_all_modules - one was run on my machine, because I'm not guessed that already runs on automated system. Everything went well - GIT is wonderful :)

I watched that tdelibs14-trinity has set Provides: tdelibs4c2a-trinity. However, it does not seem like a good idea.

While it is good that now, before rebuild all other packages, update to tdelibs14-trinity will not uninstall all other packages, but it will not work. For example tdm_gree now report that not found libtdeui.so.4 and crashes.

The package tdelibs14-trinity simply does not provide the same libraries as tdelibs4c2a-trinity.

(In reply to comment #17)
> I watched that tdelibs14-trinity has set Provides: tdelibs4c2a-trinity.
> However, it does not seem like a good idea.
> 
> While it is good that now, before rebuild all other packages, update to
> tdelibs14-trinity will not uninstall all other packages, but it will not work.
> For example tdm_gree now report that not found libtdeui.so.4 and crashes.
> 
> The package tdelibs14-trinity simply does not provide the same libraries as
> tdelibs4c2a-trinity.

Fixed in GIT hash ac583d0.

It looks like this report is resolved, closing.