I have a CentOS 4.1 box running Dag's Wieers kannel 1.4.0-3.2.el4.rf package which has a dependency on sqlite version 2.8.16-1.2.el4.rf also from Dag.
If I try to up2date to centos 4.2 I'm hitting a conflict whereby 4.2 wants to install sqlite 3.2.2 - but kannel doesn't like that, reporting:
Unresolvable chain of dependencies: kannel 1.4.0-3.2.el4.rf requires libsqlite.so.0
The new 3.2.2 version only provides libsqlite3.so.0.
Anyone else seen this, or have any recommendations as to how I can have 4.2with kannel still installed?
-- Cheers,
Tony
Tony wrote:
Unresolvable chain of dependencies: kannel 1.4.0-3.2.el4.rf requires libsqlite.so.0
The new 3.2.2 version only provides libsqlite3.so.0.
Anyone else seen this, or have any recommendations as to how I can have 4.2with kannel still installed?
-- Cheers,
Tony
If you just need to get it in there, you can force the install after making a symlink from libsqlite.so.0 to libsqlite3.so.0. You would use "ln -s" to do this. "ln --help" will provide you with syntax, I believe it is "ln -s libsqlite3.so.0 libsqlite.so.0"
This is not a way to solve the dependency, after you do this you will have to force (--force) the rpm install of the rpm after downloading it manually.
I only use yum to install a few apps and to update, I've not run into this problem before using yum. I would wait for more advice on the issue unless this is somewhat urgent.
HTH
Alex White
hi,
which has a dependency on sqlite version 2.8.16-1.2.el4.rf also from Dag.
does the sqlite2 packages from Dag's repo conflict with sqlite3 packages from official repo ? If they don't then install sqlite2 packages.
Unresolvable chain of dependencies: kannel 1.4.0-3.2.el4.rf requires libsqlite.so.0
hmm. Try to create a symlink with name libsqlite.so.0 pointing to libsqlite3.so.0. And install kannel with nodeps flag. Maybe it will work, maybe not. As I remember sqlite3 not (fully) compatible with sqlite2 API.
bye, Ago
On 11/10/05, Deim Ágoston ago@lsc.hu wrote:
which has a dependency on sqlite version 2.8.16-1.2.el4.rf also from
Dag.
does the sqlite2 packages from Dag's repo conflict with sqlite3 packages
from official repo ? If they don't then install sqlite2 packages.
The two packages appear to not overlap in terms of the files that they install - and according to the sqlite website, sqlite3 should happily work alongside sqlite (meaning versions <3). I think the problem lies in that the centos team chose to call their package sqlite rather than sqlite3, so accidentally clashing with Dag's rpmforge package name. I think I'll be able to get away with forcing the upgrade of sqlite v3 and then I'll manually put back the sqlite 2.8.16 files so that kannel is still happy. Since it's a live system, I'll need to go practice on something else first though!
Try to create a symlink with name libsqlite.so.0 pointing to libsqlite3.so.0. And install kannel with nodeps flag. Maybe it will work, maybe not. As I remember sqlite3 not (fully) compatible with sqlite2 API.
And the database file formats have apparently changed significantly too. I'll be needing yum to use one system and kannel to use the older one, so symlinking the two together is frightening!
-- Cheers,
Tony
The two packages appear to not overlap in terms of the files that they install - and according to the sqlite website, sqlite3 should happily work alongside sqlite (meaning versions <3). I think the problem lies in that
I agree. We have systems where these two versions co-exist happier. From source :)
centos team chose to call their package sqlite rather than sqlite3, so accidentally clashing with Dag's rpmforge package name. I think I'll be
I think you can blame on RedHat. They chose the package names. Don't forget that CentOS tem "just" rebuild the source rpms. To be fully compatible they even mirror the bugs... (eg.: anaconda installer bug with raid1 root partition and grub)
bye, Ago
On 11/11/05, Deim Ágoston ago@lsc.hu wrote:
centos team chose to call their package sqlite rather than sqlite3, so accidentally clashing with Dag's rpmforge package name. I think I'll be
I think you can blame on RedHat. They chose the package names. Don't forget that CentOS tem "just" rebuild the source rpms. To be fully compatible they even mirror the bugs... (eg.: anaconda installer bug with raid1 root partition and grub)
No blame coming from here- I try not to do blame culture, and especially in this case given that the Centos folks do an amazing job for free - and can't be expected to test against 3rd party repositories like Dags.
I'm pretty sure it's not from RedHat, though under normal circumstances you'd be right. If I read the centos 4.2 release notes correctly, their sqlite package has come in to improve yum performance as part of the centos replacement for the Redhat Network.
It would be cool if centos could change their package name to sqlite3 and make that come through to replace their sqlite package asap, but I don't know if that type of update is even possible, let alone warranted given the tiny minority (1?) who are probably affected by it versus the risks of screwing up a bunch of other people's happy centos4.2 systems.
-- Cheers,
Tony
On Fri, 2005-11-11 at 00:24 +0000, Tony wrote:
On 11/11/05, Deim Ágoston ago@lsc.hu wrote:
> centos team chose to call their package sqlite rather than sqlite3, so > accidentally clashing with Dag's rpmforge package name. I think I'll be I think you can blame on RedHat. They chose the package names. Don't forget that CentOS tem "just" rebuild the source rpms. To be fully compatible they even mirror the bugs... (eg.: anaconda installer bug with raid1 root partition and grub)
No blame coming from here- I try not to do blame culture, and especially in this case given that the Centos folks do an amazing job for free - and can't be expected to test against 3rd party repositories like Dags.
I'm pretty sure it's not from RedHat, though under normal circumstances you'd be right. If I read the centos 4.2 release notes correctly, their sqlite package has come in to improve yum performance as part of the centos replacement for the Redhat Network.
It would be cool if centos could change their package name to sqlite3 and make that come through to replace their sqlite package asap, but I don't know if that type of update is even possible, let alone warranted given the tiny minority (1?) who are probably affected by it versus the risks of screwing up a bunch of other people's happy centos4.2 systems.
The sqlite package does come from the upstream provider ... just not the RHEL branch, it is from the fedora branch. That is what we do ... take the upstream code as is.
I know that it does conflict with Dag's sqlite 2 .. and I am sorry, but we need to maintain compatibility with the upstream provider, since if we add other items that use sqlite, we will need to have that compatibility.
On Thu, 10 Nov 2005, Johnny Hughes wrote:
The sqlite package does come from the upstream provider ... just not the RHEL branch, it is from the fedora branch. That is what we do ... take the upstream code as is.
I know that it does conflict with Dag's sqlite 2 .. and I am sorry, but we need to maintain compatibility with the upstream provider, since if we add other items that use sqlite, we will need to have that compatibility.
I'm not familiar with the problem, are we using a package-name that has been obsoleted in some way ? Or are files conflicting ?
If we can improve our packages to fix this somehow, keep us informed too.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On 11/14/05, Dag Wieers dag@wieers.com wrote:
On Thu, 10 Nov 2005, Johnny Hughes wrote:
I know that it does conflict with Dag's sqlite 2 .. and I am sorry, but we need to maintain compatibility with the upstream provider, since if we add other items that use sqlite, we will need to have that compatibility.
Fair enough - using FC's sqlite srpm makes complete sense to me.
I'm not familiar with the problem, are we using a package-name that has
been obsoleted in some way ? Or are files conflicting ?
Dag- there are no internal file conflicts between the two sqlite rpms - I solved my problem with "rpm -ivh sqlite-3.2.2-1.i386.rpm" and now have both sqlite packages happily sitting side by side. The problem came earlier when an up2date -u wanted to replace your sqlite package with the new centos 4.2one- but your kannel package needs your sqlite as the new package is really sqlite3. RHEL users of your kannel package won't be affected, and hopefully any other centos4 users will find this mail thread or have solved it for themselves way faster than I did. If you rebuild your kannel against the new centos sqlite library then you break RHEL users. I suppose you could change your sqlite package to be called sqlite2 to avoid the clash, but I guess that would give you all sorts of other dependency changes elsewhere in your repo.
I don't know enough about how packages obsolete each other. Maybe the problem is that the FC/centos4 sqlite rpm should have something in it to say that it doesn't obsolete sqlite versions < 3?
-- Cheers,
Tony
On Monday 14 November 2005 05:20 pm, Tony wrote:
Dag- there are no internal file conflicts between the two sqlite rpms - I solved my problem with "rpm -ivh sqlite-3.2.2-1.i386.rpm" and now have both sqlite packages happily sitting side by side. The problem came earlier when an up2date -u wanted to replace your sqlite package with the new centos 4.2one- but your kannel package needs your sqlite as the new package is really sqlite3. RHEL users of your kannel package won't be affected, and hopefully any other centos4 users will find this mail thread or have solved it for themselves way faster than I did. If you rebuild your kannel against the new centos sqlite library then you break RHEL users. I suppose you could change your sqlite package to be called sqlite2 to avoid the clash, but I guess that would give you all sorts of other dependency changes elsewhere in your repo.
I don't know enough about how packages obsolete each other. Maybe the problem is that the FC/centos4 sqlite rpm should have something in it to say that it doesn't obsolete sqlite versions < 3?
Hi Tony, I am trying to install kannel too on Centos 4.2. But unfortunately I'm not following you.
What steps should I do to install it?
This is the steps that I have tried: 1. Install using yum from dag, it complained about missing dependencies: libsqlite.so.0 2. Download and try to install sqlite2 manually using rpm ivh, but it says that there is newer version already installed.
Thanks.
On Monday 20 March 2006 03:48 pm, Fajar Priyanto wrote:
Hi Tony, I am trying to install kannel too on Centos 4.2. But unfortunately I'm not following you.
What steps should I do to install it?
This is the steps that I have tried:
- Install using yum from dag, it complained about missing dependencies:
libsqlite.so.0 2. Download and try to install sqlite2 manually using rpm ivh, but it says that there is newer version already installed.
Hi all, After reading Tony's post several times, I guess my problem is very similar. The real difference is that he was trying to upgrade his centos from 4.1 to 4.2, while I was trying to install kannel on 4.2 whose got newer sqlite.
So I did this: rpm -ivh --force sqlite-2.8.16-1.2.el4.rf.i386.rpm
And then used yum to install kannel. So far so good. I documented this in: http://linux2.arinet.org/index.php?option=com_content&task=view&id=1...
HTH,