10:31 p.m.
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
1:04 a.m.
2010/6/30 Rich Mattes <richmattes(a)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
[1]: http://koji.fedoraproject.org/koji/taskinfo?taskID=2282066
--
See https://bugzilla.redhat.com/show_bug.cgi?id=607554
3:23 a.m.
On Wed, 30 Jun 2010 14:04:51 +0800, Chen wrote:
2010/6/30 Rich Mattes <richmattes(a)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
>
> [1]: http://koji.fedoraproject.org/koji/taskinfo?taskID=2282066
>
> --
See https://bugzilla.redhat.com/show_bug.cgi?id=607554
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".
4:21 a.m.
2010/6/30 Michael Schwendt <mschwendt(a)gmail.com>:
On Wed, 30 Jun 2010 14:04:51 +0800, Chen wrote:
> 2010/6/30 Rich Mattes <richmattes(a)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
> >
> > [1]: http://koji.fedoraproject.org/koji/taskinfo?taskID=2282066
> >
> > --
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=607554
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
4:25 a.m.
On Wed, Jun 30, 2010 at 10:21 AM, Chen Lei <supercyper1(a)gmail.com> wrote:
2010/6/30 Michael Schwendt <mschwendt(a)gmail.com>:
> On Wed, 30 Jun 2010 14:04:51 +0800, Chen wrote:
>
>> 2010/6/30 Rich Mattes <richmattes(a)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
>> >
>> > [1]: http://koji.fedoraproject.org/koji/taskinfo?taskID=2282066
>> >
>> > --
>>
>> See https://bugzilla.redhat.com/show_bug.cgi?id=607554
>
> 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
4:35 a.m.
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.
6:59 a.m.
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
7:04 a.m.
2010/6/30 Rich Mattes <richmattes(a)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
4:42 a.m.
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.
7:02 a.m.
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.
7:06 a.m.
2010/6/30 Michael Schwendt <mschwendt(a)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
9:04 a.m.
On Wed, Jun 30, 2010 at 8:06 AM, Chen Lei <supercyper1(a)gmail.com> wrote:
2010/6/30 Michael Schwendt <mschwendt(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
10:11 a.m.
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.
--
James Antill - james(a)fedoraproject.org
http://yum.baseurl.org/wiki/whatsnew/3.2.28
http://yum.baseurl.org/wiki/YumBenchmarks
http://yum.baseurl.org/wiki/YumHistory
10:16 a.m.
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:
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.
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
10:29 a.m.
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:
>
> 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.
>
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.
10:34 a.m.
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:
> >
> > 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.
> >
>
>
> 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
11:55 a.m.
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
12:06 p.m.
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
12:10 p.m.
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
12:46 p.m.
On Wed, Jun 30, 2010 at 12:10:11 -0500,
Rex Dieter <rdieter(a)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).
1:49 p.m.
2010/7/1 Bruno Wolff III <bruno(a)wolff.to>:
On Wed, Jun 30, 2010 at 12:10:11 -0500,
Rex Dieter <rdieter(a)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(a)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
7:26 a.m.
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
--
Adam Tkac, Red Hat, Inc.
8:55 a.m.
2010/7/1 Adam Tkac <atkac(a)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:
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
--
Only three packages in the rawhide depend on -utils:
renrot
gallery2-jpegtran
gocr
Chen Lei
9:20 a.m.
On Thu, Jul 01, 2010 at 09:55:08PM +0800, Chen Lei wrote:
2010/7/1 Adam Tkac <atkac(a)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:
>
> 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
>
> --
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
--
Adam Tkac, Red Hat, Inc.
10:59 a.m.
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:
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?
solution #1 seems like the logical choice.
-Toshio
5048
days inactive
5049
days old
24 comments
11 participants
participants (11)
-
Adam Tkac -
Bruno Wolff III -
Chen Lei -
James Antill -
Michael Schwendt -
Peter Robinson -
Ralf Ertzinger -
Rex Dieter -
Rich Mattes -
Seth Vidal -
Toshio Kuratomi