Dne pá 28. listopadu 2014 Timothy Pearson napsal(a):

...

Tim, I made a new rebuild yesterday night (everything except the applications folder) and update the system this morning. I encountered dependency conflicts in tdepim. For example: libkcal2b-trinity conflicts with libtdepim1-trinity-dev I can resolve those by removing 3 packages:

• kipi-plugins-trinity
• libkcal2-trinity-dev
• libkcal2b-trinity

Until 6 days ago (my previous build) no conflicts whatsoever. Just thought I would let you know. Is it something to be expect due to some recent changes made in between RC1 and RC2?

Cheers Michele

A change was made between RC1 and RC2 to remove a circular dependency by merging (IIRC) libkcal2b-trinity into libtdepim1-trinity. I'm guessing Slavek forgot to add a Replaces line to the newly merged package?

Tim

I can confirm that is set Replaces and Conflicts (to ensure removal libkcal2b-trinity before unpacking updated libtdepim1-trinity). During installation, aptitude only shows attention on removing libkcal2b-trinity, but the installation process is smooth.

On Friday 28 of November 2014 22:26:13 Mike Bird wrote:

FWIW an "apt-get update" a few minutes ago still shows RC14 RC1 version of kipi-plugins-trinity (4:14.0.0-r194-0debian7.0.0+pr23) which still depends on libkcal2b-trinity. Most packages (e.g. kalarm-trinity) have been rebuilt and lost that dependency.

Packages still depending on libkcal2b-trinity are:

kpilot-trinity kbugbuster-trinity kipi-plugins-trinity

--Mike

This is precisely why libtdepim1-trinity has also set:

Provides: libkcal2b-trinity

This ensures that the packages will not lose their dependence => do not need immediately rebuild.

On Saturday 29 of November 2014 01:51:56 Mike Bird wrote:

On Fri November 28 2014 16:34:05 Slávek Banko wrote:

...

This is precisely why libtdepim1-trinity has also set:

Provides: libkcal2b-trinity

This ensures that the packages will not lose their dependence => do not need immediately rebuild.

This is one of those horrible corner cases, see Debian Policy Manual 7.5:

https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual

libkcal2b-trinity is now a virtual package, and virtual packages cannot satisfy versioned dependencies:

The following packages have unmet dependencies: kipi-plugins-trinity : Depends: libkcal2b-trinity (>= 4:3.5.7)

--Mike

Yes, just studying the same thing - Provides simply not solve versioned dependency. Solutions are therefore two:

1) Rebuild all affected packages => including fix dependencies in tde-packaging.

2) Instead of a virtual package libkcal2b-trinity create a "transitional dummy" package.

Note: Fix remaining dependence on libkcal2b-trinity and libkcal2b-trinity-dev in tde-packaging is desirable in any case.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224

On Friday 28 of November 2014 22:26:13 Mike Bird wrote:

...

FWIW an "apt-get update" a few minutes ago still shows RC14 RC1 version of kipi-plugins-trinity (4:14.0.0-r194-0debian7.0.0+pr23) which still depends on libkcal2b-trinity. Most packages (e.g. kalarm-trinity) have been rebuilt and lost that dependency.

Packages still depending on libkcal2b-trinity are:

kpilot-trinity kbugbuster-trinity kipi-plugins-trinity

--Mike

Ok, I looked at it again in detail - really set Provides does not solve the situation satisfactorily. I'll look at it closer.

I'm rebuilding those three packages so that we can keep RC2 on schedule.

Tim