Bug#538399: /usr/bin/apt-get: fails to upgrade dependencies
Hi Michal Suchanek,
> As I see it pinning is only a hint as to what packages I prefer. For
> one, if I install an unstable package and a newer version is uploaded
> into unstable then that version should be installed, too, regardless
> of pinning other repository higher.
Goswin von Brederlow is absolutely right here, apt has a very strict
interpretation of Pins. This simplify many things in apt and is also one
of the key features of apt: It never tries to guess what the user maybe
want, it only try to do what the user said.
> apt-get is pretty much useless for me otherwise.
If you don't like this behavior then apt is simply not for you.
But don't worry: There is a tool which seems to do all what you want
and his name is: aptitude
apts goal isn't (and will hopefully never be) to become an aptitude-clone.
aptitude is simply a much better aptitude than apt will ever be...
But your are right that it would be great if apt would display more
information about why it refuses to do what it was commanded to do:
The current display is okay and with a bit of practice quite good to
understand but it can always be improved a bit. If you have more detailed
ideas about that or even a patch feel free to sent it to the mailing list
or publish your branch. :)
>> ia32-apt-get -t sid install xinput
>> or
>> ia32-apt-get -t unstable install xinput
>> One of the two works the other doesn't. -t is a bit picky iirc.
In version 0.7.21 and lower only the -t unstable version will work.
A patch for the -t sid version is applied in the bazaar branch and
will be very likely part of 0.7.22.
Note, that this will enable Codename-support everywhere,
where you previously are only able to use archive names,
e.g. also in perferences-file(s).
> I guess it should have been
> -t sid install
> or
> install -t sid
> and that only one works is yet another bug which is already reported
> (and unfixed) iirc.
As i said before, the -t sid will not work until 0.7.22, but the order of
the flags has no effect, so both commands will be equal after the 0.7.22
release (currently they are also both equal as they have both no effect).
Maybe you mean that sometimes it is a difference if you do:
apt-get install A B or apt-get install B A to install package A and B, but
this is a different story and will hopefully be addressed in the future...
(i played with a ugly patch for this already, but a better patch will require
a bit more work and time and is currently not that high on my personal
priority list ~ so feel free to adopt the issue and fix it if you want. :)
Best regards / Mit freundlichen Grüßen,
David "DonKult" Kalnischkies
Reply to: