Re: Help debugging package problems (again)
On Sun, 2 Feb 2003 17:43:29 -0800 (PST), Bill Moseley <moseley@hank.org> wrote:
> [back to list]
>
> On Sun, 2 Feb 2003, Faheem Mitha wrote:
>
>> > ii libc6 2.3.1-9 GNU C Library: Shared libraries and Timezone data
>>
>> As I am sure hordes of people will shortly tell you, you have upgraded
>> to the libc6 in unstable. In general, not such a great idea. Now some
>> of the packages in testing are going to be uninstallable for you, and
>> you may have other problems. Be careful about upgrading packages from
>> unstable. In general you don't want to upgrade base packages,
>> particularly libc and c++ libraries and perl. locales in testing
>> depends on a particular value of libc6
>
> That's probably what happened. So a program has a bug fix or a feature
> that's required and it's in unstable what options do I have?
Compile the deb sources from unstable into a deb which you then
install with "dpkg -i" (if possible). Yes, this is not ideal, but the
other option is just to stay with stable or track unstable, and both
those options have their own problems. Some of the Debian developers
are on record as saying they don't think testing is such a great idea,
since you don't get security updates in testing etc.
>> In some cases it is possible to recompile packages from unstable
>> locally, and it this is possible, do it. But they might have too many
>> dependencies that are only in unstable for such an approach to be
>> practical. The new apt-src by Joey Hess (only in unstable currently)
>> might help with that.
>
> I'll take a look. At some point it almost seems easier to just build from
> source. I've been trying to avoid that as much as possible. But maybe
> it's worse to break things my mixing up testing and unstable.
Just to clarify, when I say build from sources, do you mean compile
the deb sources? Because this is what I mean.
Apparently apt-src gives the long-awaited functionality of compiling
from sources and recursively compiling the build dependencies if they
are not sufficiently up to date. (This is a real pain to handle
manually.) Sort of ports-like functionality. So once it is available,
it will make things easier. I'm not aware of any backports to testing,
unfortunately.
>> You might try downgrading libc to testing. Warning: this might break
>> your system. Apt-get will give you horrible warnings if you try to do
>> this, but if your system is still mostly testing, it may well
>> work. Try
>>
>> apt-get install libc6/testing
>
> Using apt-get -s install libc6/testing says it's going to remove over 200
> packages.
>
> bumby:~# dpkg -l | grep ^ii | wc -l
> 487
> bumby:~# apt-get -s install libc6/testing | grep Remv | wc -l
> 219
>
>
> Doesn't make sense. It's removing packages that are in testing. For
> example:
>
> Remv aumix-gtk (2.7-26 Debian:testing)
>
> I think that downgrade would really break things
Hmm. This may be because you may now have testing packages which
depend on packages which are now installed as the unstable version
(since many dependencies just say >= something). If the unstable
packages are now pulled out (since you are not telling apt to replace
them with the testing version) then the testing packages get pulled
out as well. This is just speculation, but you could take a look at
the dependency structure and see. Check and see how many packages you
now have from unstable.
A better option might be to force a mass downgrade using apt
preferences. If you put /etc/apt/prefences
Package: *
Pin: release a=testing
Pin-Priority: 1001
Then all the packages in testing will have sufficiently high priority
to overcome the downgrade prevention barrier. Since this is allowing
the option to back up all unstable packages to testing versions, it
may result in the removal of less packages.
Whether it breaks the system or not would depend on whether it is
going to mess with the base packages. Certainly there are no
guarantees. You are presumably aware that mass downgrading is *not*
officially supported.
Faheem.
Reply to: