[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#794093: marked as done (libnepomuk4: Please loosen the versioned dependency on libkdecore5 and libkdeui5 from '=' to '>=')

Your message dated Sun, 21 Aug 2016 13:28:15 +0200
with message-id <122664895.fgnfptqRUW@pendragon>
and subject line Re: Bug#794093: libnepomuk4: Please loosen the versioned dependency on libkdecore5 and libkdeui5 from '=' to '>='
has caused the Debian Bug report #794093,
regarding libnepomuk4: Please loosen the versioned dependency on libkdecore5 and libkdeui5 from '=' to '>='
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
794093: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794093
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libnepomuk4
Version: 4:4.14.2-5
Severity: wishlist

I wanted to upgrade various libraries from the unstable version to the
experimental version in the hope that it would solve some odd behaviour
in dolphin's Places section (which it did).
But doing that I had to uninstall various nepomuk related libraries and
programs that depend on them (yakuake, but also muon which I don't use).

This is caused because libnepomuk4, libnepomukquery4a and
libnepomukutils4 have a strict versioned dependency on libkdecore5 and
libkdeui5 (= 4:4.14.2-5) and the version in experimental of those
libraries is 4:4.14.6-1. 
Oddly enough, libnepomukcore4 (version 4:14.0-1+b3) also has a
dependency on those libraries, but there the versioned dependency is
>=4:4.13.
It would be great if the other nepomuk libraries could also have a
similar versioned dependency, thus '>=' instead of '='.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libnepomuk4 depends on:
ii  libc6        2.19-19
ii  libkdecore5  4:4.14.6-1
ii  libkdeui5    4:4.14.6-1
ii  libqt4-dbus  4:4.8.7+dfsg-1
ii  libqtcore4   4:4.8.7+dfsg-1
ii  libqtgui4    4:4.8.7+dfsg-1
ii  libsoprano4  2.9.4+dfsg-1.1
ii  libstdc++6   5.1.1-14

libnepomuk4 recommends no packages.

libnepomuk4 suggests no packages.

--- End Message ---
--- Begin Message --- 
Hi,

sorry for the late reply.

In data giovedì 30 luglio 2015 14:49:39 CEST, Diederik de Haas ha scritto:
> I wanted to upgrade various libraries from the unstable version to the
> experimental version in the hope that it would solve some odd behaviour
> in dolphin's Places section (which it did).
> But doing that I had to uninstall various nepomuk related libraries and
> programs that depend on them (yakuake, but also muon which I don't use).

Picking stuff from experimental always require attention, and due to the
way experimental works is not always possible without breaking something
else.

> This is caused because libnepomuk4, libnepomukquery4a and
> libnepomukutils4 have a strict versioned dependency on libkdecore5 and
> libkdeui5 (= 4:4.14.2-5) and the version in experimental of those
> libraries is 4:4.14.6-1. 
> Oddly enough, libnepomukcore4 (version 4:14.0-1+b3) also has a
> dependency on those libraries, but there the versioned dependency is
> >=4:4.13.
> It would be great if the other nepomuk libraries could also have a
> similar versioned dependency, thus '>=' instead of '='.

Everything that is shipped by the kde4libs source (including the
libnepomuk4 library) is considered as a "single entitity", and thus
allowing to install different versions of the libraries could cause
issues of any kind, which we wouldn't rather deal with.

Hence no, the dependency will not be loosen.

Thanks for your report,
-- 
Pino Toscano

Attachment: signature.asc
Description: This is a digitally signed message part.


--- End Message ---
Reply to: