Hi all,
I'm trying to build a package that has a BuildRequires: libjpeg-devel in Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. Unfortunately, when it pulls in dependencies for my other BuildRequires, it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict since they both provide libjpeg.so.62.0.0
The only thing I can think of is that one of the packages I'm requiring has an explicit dep on libjpeg (I'm about to investigate which). For the time being, is there any to work around this?
Thanks,
Rich
[1]: http://koji.fedoraproject.org/koji/taskinfo?taskID=2282066
2010/6/30 Rich Mattes richmattes@gmail.com:
Hi all,
I'm trying to build a package that has a BuildRequires: libjpeg-devel in Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. Unfortunately, when it pulls in dependencies for my other BuildRequires, it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict since they both provide libjpeg.so.62.0.0
The only thing I can think of is that one of the packages I'm requiring has an explicit dep on libjpeg (I'm about to investigate which). For the time being, is there any to work around this?
Thanks,
Rich
--
On Wed, 30 Jun 2010 14:04:51 +0800, Chen wrote:
2010/6/30 Rich Mattes richmattes@gmail.com:
Hi all,
I'm trying to build a package that has a BuildRequires: libjpeg-devel in Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. Unfortunately, when it pulls in dependencies for my other BuildRequires, it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict since they both provide libjpeg.so.62.0.0
The only thing I can think of is that one of the packages I'm requiring has an explicit dep on libjpeg (I'm about to investigate which). For the time being, is there any to work around this?
Thanks,
Rich
--
Why doesn't libjpeg-turbo contain the proper Obsoletes for libjpeg?
Only libjpeg-turbo-devel does it correctly for libjpeg-devel and libjpeg-static.
That's only half of the show. libjpeg-turbo is meant to replace libjpeg, so it should obsolete it. And if it also added the "Provides", there would be no need to rebuild dependencies, but considering that this is Rawhide, okay if it doesn't add the "Provides".
2010/6/30 Michael Schwendt mschwendt@gmail.com:
On Wed, 30 Jun 2010 14:04:51 +0800, Chen wrote:
2010/6/30 Rich Mattes richmattes@gmail.com:
Hi all,
I'm trying to build a package that has a BuildRequires: libjpeg-devel in Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. Unfortunately, when it pulls in dependencies for my other BuildRequires, it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict since they both provide libjpeg.so.62.0.0
The only thing I can think of is that one of the packages I'm requiring has an explicit dep on libjpeg (I'm about to investigate which). For the time being, is there any to work around this?
Thanks,
Rich
--
Why doesn't libjpeg-turbo contain the proper Obsoletes for libjpeg?
Only libjpeg-turbo-devel does it correctly for libjpeg-devel and libjpeg-static.
That's only half of the show. libjpeg-turbo is meant to replace libjpeg, so it should obsolete it. And if it also added the "Provides", there would be no need to rebuild dependencies, but considering that this is Rawhide, okay if it doesn't add the "Provides". --
libjpeg is split into libjpeg-turbo and libjpeg-turbo-utils, Obsoletes libjpeg is already added to libjpeg-turbo-utils. I don't know why Rich's package failed to build on koji, the problem is a bit weird. Among 5 packages which require libjpeg explicitly, only java-1.6.0-openjdk will be used as a BR, however Rich's packages is irrelevant to java. FYI, provides libjpeg is also add to libjpeg-turbo-utils now, I don't know if it can solve the file conflicts. Chen Lei
On Wed, Jun 30, 2010 at 10:21 AM, Chen Lei supercyper1@gmail.com wrote:
2010/6/30 Michael Schwendt mschwendt@gmail.com:
On Wed, 30 Jun 2010 14:04:51 +0800, Chen wrote:
2010/6/30 Rich Mattes richmattes@gmail.com:
Hi all,
I'm trying to build a package that has a BuildRequires: libjpeg-devel in Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. Unfortunately, when it pulls in dependencies for my other BuildRequires, it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict since they both provide libjpeg.so.62.0.0
The only thing I can think of is that one of the packages I'm requiring has an explicit dep on libjpeg (I'm about to investigate which). For the time being, is there any to work around this?
Thanks,
Rich
--
Why doesn't libjpeg-turbo contain the proper Obsoletes for libjpeg?
Only libjpeg-turbo-devel does it correctly for libjpeg-devel and libjpeg-static.
That's only half of the show. libjpeg-turbo is meant to replace libjpeg, so it should obsolete it. And if it also added the "Provides", there would be no need to rebuild dependencies, but considering that this is Rawhide, okay if it doesn't add the "Provides". --
libjpeg is split into libjpeg-turbo and libjpeg-turbo-utils, Obsoletes libjpeg is already added to libjpeg-turbo-utils. I don't know why Rich's package failed to build on koji, the problem is a bit weird. Among 5 packages which require libjpeg explicitly, only java-1.6.0-openjdk will be used as a BR, however Rich's packages is irrelevant to java. FYI, provides libjpeg is also add to libjpeg-turbo-utils now, I don't know if it can solve the file conflicts.
Why would you add the obsolete to the -utils. In most cases you probably only need the libs so it wouldn't pull in the utils package and hence wouldn't obsolete it. You need to have the library obsolete the libary probably along with the appropriate matching provides as well.
Peter
On Wed, 30 Jun 2010 10:25:37 +0100, Peter wrote:
libjpeg is split into libjpeg-turbo and libjpeg-turbo-utils, Obsoletes libjpeg is already added to libjpeg-turbo-utils. I don't know why Rich's package failed to build on koji, the problem is a bit weird. Among 5 packages which require libjpeg explicitly, only java-1.6.0-openjdk will be used as a BR, however Rich's packages is irrelevant to java. FYI, provides libjpeg is also add to libjpeg-turbo-utils now, I don't know if it can solve the file conflicts.
Why would you add the obsolete to the -utils. In most cases you probably only need the libs so it wouldn't pull in the utils package and hence wouldn't obsolete it.
libjpeg contained libs _and_ tools.
On 6/30/2010 5:35 AM, Michael Schwendt wrote:
On Wed, 30 Jun 2010 10:25:37 +0100, Peter wrote:
libjpeg is split into libjpeg-turbo and libjpeg-turbo-utils, Obsoletes libjpeg is already added to libjpeg-turbo-utils. I don't know why Rich's package failed to build on koji, the problem is a bit weird. Among 5 packages which require libjpeg explicitly, only java-1.6.0-openjdk will be used as a BR, however Rich's packages is irrelevant to java. FYI, provides libjpeg is also add to libjpeg-turbo-utils now, I don't know if it can solve the file conflicts.
Why would you add the obsolete to the -utils. In most cases you probably only need the libs so it wouldn't pull in the utils package and hence wouldn't obsolete it.
libjpeg contained libs _and_ tools.
I played with it a little bit more last night, the problem occurred when my package pulled in graphviz. Graphviz has a BR:libjpeg-devel, and makes no mention of libjpeg-utils. It only relies on libjpeg for the libraries, and doesn't need any of the utils (my package only uses libjpeg's libraries as well). I guess since libjpeg-turbo didn't obsolete libjpeg, graphviz was quite happy pulling in libjpeg instead of libjpeg-turbo.
Rich
2010/6/30 Rich Mattes richmattes@gmail.com:
I played with it a little bit more last night, the problem occurred when my package pulled in graphviz. Graphviz has a BR:libjpeg-devel, and makes no mention of libjpeg-utils. It only relies on libjpeg for the libraries, and doesn't need any of the utils (my package only uses libjpeg's libraries as well). I guess since libjpeg-turbo didn't obsolete libjpeg, graphviz was quite happy pulling in libjpeg instead of libjpeg-turbo.
Rich
I think It's a bug of yum-builddep, libjpeg is obsoleted by libjpeg-turbo-utils, and graphviz don't depends on libjpeg explicitly, I don't know how libjpeg can be pulled in.
Chen Lei
Hi.
On Wed, 30 Jun 2010 17:21:37 +0800, Chen Lei wrote:
libjpeg is split into libjpeg-turbo and libjpeg-turbo-utils, Obsoletes libjpeg is already added to libjpeg-turbo-utils.
I assume that you cannot really install libjpeg-turbo-utils without pulling in libjpeg-turbo, so the the obsoletes should be on the package containing the libs.
On Wed, 30 Jun 2010 17:21:37 +0800, Chen wrote:
libjpeg is split into libjpeg-turbo and libjpeg-turbo-utils, Obsoletes libjpeg is already added to libjpeg-turbo-utils.
root.log of http://koji.fedoraproject.org/koji/taskinfo?taskID=2282066 doesn't refer to libjpeg-turbo-utils at all, but just libjpeg *and* libjpeg-turbo.
2010/6/30 Michael Schwendt mschwendt@gmail.com:
On Wed, 30 Jun 2010 17:21:37 +0800, Chen wrote:
libjpeg is split into libjpeg-turbo and libjpeg-turbo-utils, Obsoletes libjpeg is already added to libjpeg-turbo-utils.
root.log of http://koji.fedoraproject.org/koji/taskinfo?taskID=2282066 doesn't refer to libjpeg-turbo-utils at all, but just libjpeg *and* libjpeg-turbo. --
It's weird, libjpeg is already obsoleted. See http://koji.fedoraproject.org/koji/rpminfo?rpmID=2040484
On Wed, Jun 30, 2010 at 8:06 AM, Chen Lei supercyper1@gmail.com wrote:
2010/6/30 Michael Schwendt mschwendt@gmail.com:
On Wed, 30 Jun 2010 17:21:37 +0800, Chen wrote:
libjpeg is split into libjpeg-turbo and libjpeg-turbo-utils, Obsoletes libjpeg is already added to libjpeg-turbo-utils.
root.log of http://koji.fedoraproject.org/koji/taskinfo?taskID=2282066 doesn't refer to libjpeg-turbo-utils at all, but just libjpeg *and* libjpeg-turbo. --
It's weird, libjpeg is already obsoleted. See http://koji.fedoraproject.org/koji/rpminfo?rpmID=2040484 --
So this is a bug with yum not handling package obsoletes correctly when it processes the libjpeg.so.62 dep for graphviz?
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 2010-06-30 at 10:04 -0400, Rich Mattes wrote:
So this is a bug with yum not handling package obsoletes correctly when it processes the libjpeg.so.62 dep for graphviz?
I suspect the problem is that libjpeg-turbo does not _provide_ libjpeg. So yum does:
1. pkg XYZ requires libjpeg
2. The provider for that is the libjpeg package.
3. The libjpeg package is obsoleted by libjpeg-turbo.
4. But, libjpeg-turbo doesn't provide "libjpeg", which is the requirement we are doing all this for ... so ignore the obsolete and install libjpeg.
On Wed, 2010-06-30 at 11:11 -0400, James Antill wrote:
On Wed, 2010-06-30 at 10:04 -0400, Rich Mattes wrote:
So this is a bug with yum not handling package obsoletes correctly when it processes the libjpeg.so.62 dep for graphviz?
I suspect the problem is that libjpeg-turbo does not _provide_ libjpeg. So yum does:
pkg XYZ requires libjpeg
The provider for that is the libjpeg package.
The libjpeg package is obsoleted by libjpeg-turbo.
But, libjpeg-turbo doesn't provide "libjpeg", which is the
requirement we are doing all this for ... so ignore the obsolete and install libjpeg.
except it does provide it:
repoquery --repoid=rawhide -q --requires graphviz |grep libjpeg libjpeg.so.62
repoquery --repoid=rawhide -q --provides libjpeg libjpeg = 6b-46.fc12 libjpeg(x86-32) = 6b-46.fc12 libjpeg.so.62
repoquery --repoid=rawhide -q --provides libjpeg-turbo libjpeg-turbo = 0.0.93-9.fc14 libjpeg-turbo(x86-32) = 0.0.93-9.fc14 libjpeg.so.62
repoquery --repoid=rawhide -q --obsoletes libjpeg-turbo <nothing>
is there a newer version not yet in the rawhide I have here? -sv
On Wed, 30 Jun 2010 11:16:11 -0400, seth wrote:
On Wed, 2010-06-30 at 11:11 -0400, James Antill wrote:
On Wed, 2010-06-30 at 10:04 -0400, Rich Mattes wrote:
So this is a bug with yum not handling package obsoletes correctly when it processes the libjpeg.so.62 dep for graphviz?
I suspect the problem is that libjpeg-turbo does not _provide_ libjpeg. So yum does:
pkg XYZ requires libjpeg
The provider for that is the libjpeg package.
The libjpeg package is obsoleted by libjpeg-turbo.
But, libjpeg-turbo doesn't provide "libjpeg", which is the
requirement we are doing all this for ... so ignore the obsolete and install libjpeg.
except it does provide it:
It doesn't. Only the most recent build in koji "Provides: libjpeg" in libjpeg-turbo-utils. (there are two builds only)
repoquery --repoid=rawhide -q --requires graphviz |grep libjpeg libjpeg.so.62
repoquery --repoid=rawhide -q --provides libjpeg libjpeg = 6b-46.fc12 libjpeg(x86-32) = 6b-46.fc12 libjpeg.so.62
repoquery --repoid=rawhide -q --provides libjpeg-turbo libjpeg-turbo = 0.0.93-9.fc14 libjpeg-turbo(x86-32) = 0.0.93-9.fc14 libjpeg.so.62
repoquery --repoid=rawhide -q --obsoletes libjpeg-turbo
<nothing>
is there a newer version not yet in the rawhide I have here?
The one you have doesn't have the libjpeg Provides yet.
On Wed, 2010-06-30 at 17:29 +0200, Michael Schwendt wrote:
On Wed, 30 Jun 2010 11:16:11 -0400, seth wrote:
On Wed, 2010-06-30 at 11:11 -0400, James Antill wrote:
On Wed, 2010-06-30 at 10:04 -0400, Rich Mattes wrote:
So this is a bug with yum not handling package obsoletes correctly when it processes the libjpeg.so.62 dep for graphviz?
I suspect the problem is that libjpeg-turbo does not _provide_ libjpeg. So yum does:
pkg XYZ requires libjpeg
The provider for that is the libjpeg package.
The libjpeg package is obsoleted by libjpeg-turbo.
But, libjpeg-turbo doesn't provide "libjpeg", which is the
requirement we are doing all this for ... so ignore the obsolete and install libjpeg.
except it does provide it:
It doesn't. Only the most recent build in koji "Provides: libjpeg" in libjpeg-turbo-utils. (there are two builds only)
repoquery --repoid=rawhide -q --requires graphviz |grep libjpeg libjpeg.so.62
repoquery --repoid=rawhide -q --provides libjpeg libjpeg = 6b-46.fc12 libjpeg(x86-32) = 6b-46.fc12 libjpeg.so.62
repoquery --repoid=rawhide -q --provides libjpeg-turbo libjpeg-turbo = 0.0.93-9.fc14 libjpeg-turbo(x86-32) = 0.0.93-9.fc14 libjpeg.so.62
repoquery --repoid=rawhide -q --obsoletes libjpeg-turbo
<nothing>
is there a newer version not yet in the rawhide I have here?
The one you have doesn't have the libjpeg Provides yet.
But it provides what graphviz requires....
-sv
On Wed, 2010-06-30 at 11:16 -0400, seth vidal wrote:
On Wed, 2010-06-30 at 11:11 -0400, James Antill wrote:
On Wed, 2010-06-30 at 10:04 -0400, Rich Mattes wrote:
So this is a bug with yum not handling package obsoletes correctly when it processes the libjpeg.so.62 dep for graphviz?
I suspect the problem is that libjpeg-turbo does not _provide_ libjpeg. So yum does:
except it does provide it:
repoquery --repoid=rawhide -q --requires graphviz |grep libjpeg libjpeg.so.62
Sorry, I should have just run commands to get everything correct, it's "weird" due to confusing package names/obsoletes:
# repoquery --repoid=rawhide --obsoletes libjpeg-turbo # repoquery --repoid=rawhide --obsoletes libjpeg-turbo-utils libjpeg < 6b-47 # repoquery --repoid=rawhide --provides libjpeg-turbo | fgrep .so. libjpeg.so.62 libjpeg.so.62()(64bit) # repoquery --repoid=rawhide --provides libjpeg-turbo-utils | fgrep .so. # /usr/bin/yum --disablerepo=* --enablerepo=rawhide \ --installroot /tmp/mock-tst install graphviz [...] --> Processing Dependency: libjpeg.so.62()(64bit) for package: graphviz-2.26.0-3.fc14.x86_64 Package libjpeg is obsoleted by libjpeg-turbo-utils, but obsoleting package does not provide for requirements
James Antill wrote:
# repoquery --repoid=rawhide --provides libjpeg-turbo-utils | fgrep .so. # /usr/bin/yum --disablerepo=* --enablerepo=rawhide \ --installroot /tmp/mock-tst install graphviz [...] --> Processing Dependency: libjpeg.so.62()(64bit) for package: graphviz-2.26.0-3.fc14.x86_64 Package libjpeg is obsoleted by libjpeg-turbo-utils, but obsoleting package does not provide for requirements
aand -utils doesn't have a Requires: on it's parent pkg, which doesn't help here. I'll go add that...
-- Rex
Rex Dieter wrote:
James Antill wrote:
# repoquery --repoid=rawhide --provides libjpeg-turbo-utils | fgrep .so. # /usr/bin/yum --disablerepo=* --enablerepo=rawhide \ --installroot /tmp/mock-tst install graphviz [...] --> Processing Dependency: libjpeg.so.62()(64bit) for package: graphviz-2.26.0-3.fc14.x86_64 Package libjpeg is obsoleted by libjpeg-turbo-utils, but obsoleting package does not provide for requirements
and -utils doesn't have a Requires: on it's parent pkg, which doesn't help here. I'll go add that...
Another wrinkle here is both libjpeg and libjpeg-turbo existing in rawhide/repo. Shouldn't libjpeg get removed now? Doing so should help matters too.
-- Rex
On Wed, Jun 30, 2010 at 12:10:11 -0500, Rex Dieter rdieter@math.unl.edu wrote:
Another wrinkle here is both libjpeg and libjpeg-turbo existing in rawhide/repo. Shouldn't libjpeg get removed now? Doing so should help matters too.
If someone looks at that, they might also want to look at dropping 'man' which is in a similar situation (obsoleted, but still hanging around).
2010/7/1 Bruno Wolff III bruno@wolff.to:
On Wed, Jun 30, 2010 at 12:10:11 -0500, Rex Dieter rdieter@math.unl.edu wrote:
Another wrinkle here is both libjpeg and libjpeg-turbo existing in rawhide/repo. Shouldn't libjpeg get removed now? Doing so should help matters too.
If someone looks at that, they might also want to look at dropping 'man' which is in a similar situation (obsoleted, but still hanging around). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libjpeg should be removed before mass-rebuild, because libjpeg-turbo provides: libjpeg-6b-47, the current libjpeg in the repo provides libjpeg-6b-46. I think there are no perfect solution for renaming/splitting packages, we should fix those broken dependencies finally instead of staying on workaround.
Chen Lei
On Tue, Jun 29, 2010 at 11:31:45PM -0400, Rich Mattes wrote:
Hi all,
Hello,
I'm trying to build a package that has a BuildRequires: libjpeg-devel in Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. Unfortunately, when it pulls in dependencies for my other BuildRequires, it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict since they both provide libjpeg.so.62.0.0
The only thing I can think of is that one of the packages I'm requiring has an explicit dep on libjpeg (I'm about to investigate which). For the time being, is there any to work around this?
I read this thread and https://bugzilla.redhat.com/show_bug.cgi?id=609224 and I see two reasonable solutions for this problem:
1. Add Obsoletes/Provides libjpeg directly to libjpeg-turbo package which contains only libjpeg.so.62*. I believe this will solve both update and buildroot problems. However it also means all users of libjpeg programs (djpeg, cjpeg and friends) will need to manually install libjpeg-turbo-tools
2. Merge both libjpeg-turbo-utils and libjpeg-turbo to one package, as done in libjpeg.
I must admit I like the first solution. People usually needs only libjpeg.so, not programs. People which need libjpeg programs can easily install libjpeg-turbo-tools package themselves, this "incompatibility" seems acceptable for me in development branch.
What is your opinion about this proposal?
Regards, Adam
2010/7/1 Adam Tkac atkac@redhat.com:
On Tue, Jun 29, 2010 at 11:31:45PM -0400, Rich Mattes wrote:
Hi all,
Hello,
I'm trying to build a package that has a BuildRequires: libjpeg-devel in Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. Unfortunately, when it pulls in dependencies for my other BuildRequires, it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict since they both provide libjpeg.so.62.0.0
The only thing I can think of is that one of the packages I'm requiring has an explicit dep on libjpeg (I'm about to investigate which). For the time being, is there any to work around this?
I read this thread and https://bugzilla.redhat.com/show_bug.cgi?id=609224 and I see two reasonable solutions for this problem:
- Add Obsoletes/Provides libjpeg directly to libjpeg-turbo package
which contains only libjpeg.so.62*. I believe this will solve both update and buildroot problems. However it also means all users of libjpeg programs (djpeg, cjpeg and friends) will need to manually install libjpeg-turbo-tools
- Merge both libjpeg-turbo-utils and libjpeg-turbo to one package, as
done in libjpeg.
I must admit I like the first solution. People usually needs only libjpeg.so, not programs. People which need libjpeg programs can easily install libjpeg-turbo-tools package themselves, this "incompatibility" seems acceptable for me in development branch.
What is your opinion about this proposal?
Regards, Adam
--
Only three packages in the rawhide depend on -utils:
renrot gallery2-jpegtran gocr
Chen Lei
On Thu, Jul 01, 2010 at 09:55:08PM +0800, Chen Lei wrote:
2010/7/1 Adam Tkac atkac@redhat.com:
On Tue, Jun 29, 2010 at 11:31:45PM -0400, Rich Mattes wrote:
Hi all,
Hello,
I'm trying to build a package that has a BuildRequires: libjpeg-devel in Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. Unfortunately, when it pulls in dependencies for my other BuildRequires, it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict since they both provide libjpeg.so.62.0.0
The only thing I can think of is that one of the packages I'm requiring has an explicit dep on libjpeg (I'm about to investigate which). For the time being, is there any to work around this?
I read this thread and https://bugzilla.redhat.com/show_bug.cgi?id=609224 and I see two reasonable solutions for this problem:
- Add Obsoletes/Provides libjpeg directly to libjpeg-turbo package
which contains only libjpeg.so.62*. I believe this will solve both update and buildroot problems. However it also means all users of libjpeg programs (djpeg, cjpeg and friends) will need to manually install libjpeg-turbo-tools
- Merge both libjpeg-turbo-utils and libjpeg-turbo to one package, as
done in libjpeg.
I must admit I like the first solution. People usually needs only libjpeg.so, not programs. People which need libjpeg programs can easily install libjpeg-turbo-tools package themselves, this "incompatibility" seems acceptable for me in development branch.
What is your opinion about this proposal?
Regards, Adam
--
Only three packages in the rawhide depend on -utils:
renrot gallery2-jpegtran gocr
Thanks for your inspection. Those packages can be very easily fixed by adding "Requires: /usr/bin/djpeg" to them. This change will be compatible with both former "monolitic" libjpeg and new libjpeg-turbo-utils. I will do this myself.
Regards, Adam
On Thu, Jul 01, 2010 at 02:26:57PM +0200, Adam Tkac wrote:
On Tue, Jun 29, 2010 at 11:31:45PM -0400, Rich Mattes wrote:
Hi all,
Hello,
I'm trying to build a package that has a BuildRequires: libjpeg-devel in Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. Unfortunately, when it pulls in dependencies for my other BuildRequires, it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict since they both provide libjpeg.so.62.0.0
The only thing I can think of is that one of the packages I'm requiring has an explicit dep on libjpeg (I'm about to investigate which). For the time being, is there any to work around this?
I read this thread and https://bugzilla.redhat.com/show_bug.cgi?id=609224 and I see two reasonable solutions for this problem:
- Add Obsoletes/Provides libjpeg directly to libjpeg-turbo package
which contains only libjpeg.so.62*. I believe this will solve both update and buildroot problems. However it also means all users of libjpeg programs (djpeg, cjpeg and friends) will need to manually install libjpeg-turbo-tools
- Merge both libjpeg-turbo-utils and libjpeg-turbo to one package, as
done in libjpeg.
I must admit I like the first solution. People usually needs only libjpeg.so, not programs. People which need libjpeg programs can easily install libjpeg-turbo-tools package themselves, this "incompatibility" seems acceptable for me in development branch.
What is your opinion about this proposal?
solution #1 seems like the logical choice.
-Toshio
-
Adam Tkac -
Bruno Wolff III -
Chen Lei -
James Antill -
Michael Schwendt -
Peter Robinson -
Ralf Ertzinger -
Rex Dieter -
Rich Mattes -
Seth Vidal -
Toshio Kuratomi