trinity-users@lists.pearsoncomputing.net

Message: previous - next
Month: September 2012

Re: [trinity-users] libogg0 conflicts with libogg0:i386 under ubuntu precise

From: Slávek Banko <slavek.banko@...>
Date: Tue, 18 Sep 2012 03:06:57 +0200
On Wednesday 25 of July 2012 18:46:37 Timothy Pearson wrote:
> > Timothy Pearson wrote:
> >>> Stefan Endrullis wrote:
> >>>> I'm using trinity on a 64 bit Ubuntu precise (12.04) installation and
> >>>> I want to report a very annoying bug caused by a package conflict of
> >>>> libogg0 from the trinity repository:
> >>>>   https://bugs.launchpad.net/trinity-desktop/+bug/977103
> >>>>
> >>>> Since trinity's libogg0 conflicts with Ubuntu libogg0:i386 several 32
> >>>> bit applications such as adobe reader can no longer be installed on 64
> >>>> bit trinity installations.
> >>>>
> >>>> Is there really a conflict between libogg0 and libogg0:i386 that needs
> >>>> to be in the package definition or can one just remove this tag?
> >>>
> >>> *BUMP*
> >>>
> >>> This problem is still there and causing major issues on recent Ubuntu
> >>> installations. Is there any reason for Trinity to ship its own libogg0?
> >>
> >> Only to provide a .la file that was removed some time ago by Ubuntu
> >> upstream.  3.5.13 needed that file to build, R14 may not due to build
> >> system fixes.
> >
> > Would it be possible to remove the offending packages from the
> > repository? This would solve all the multi-arch issues. Another option
> > would be adding "Multi-Arch: same".
> >
> > Julius
>
> Just so I fully understand the problem, is this problem occurring with the
> nightly builds on Precise, or is it occurring with the 3.5.13 repository
> forcibly installed onto Precise?
>
> Thanks!
>
> Tim
>

Tim,

I tried to find some information about the problem with the concurrent 
installation libogg:amd64 and libogg:i386. And I find a little mystery. When 
I add a apt source nighlty-build-deps, this library is in the conflict when I 
try to install both in the aptitude. But if I download these packages and 
install both packages manually using dpkg, so the conflict does not occur. As 
the information about the conflict was somewhere in the information for apt.

This would confirm the fact that when I install a library from my local apt 
source managed by reprepro, so the conflict does not occur.

What could be wrong in apt source managed by Launchpad?
Within the package clearly not the problem.

Slavek
--