Re: apt pinning question
On Wed, Mar 30, 2011 at 03:35:13PM -0500, Boyd Stephen Smith Jr. wrote:
> Looks broken to me, as well. Perhaps this is worth a bug report? At the very
Yeah, that's next. I was hoping I was missing something.
> Nothing in /etc/apt/preferences.d? What's the output of (apt-cache policy |
> awk 'BEGIN { p = 0 } /^Pinned packages:/ { p = 1 } { if (p) print }')?
Pinned packages:
dovecot-imapd -> 1:1.2.15-1~bpo50+1
> Try adding this to your preferences:
> Package: dovecot-imapd
> Pin: release a=oldstable
> Pin-Priority: 750
I tried that. It doesn't help. The winner depends on their order
of appearance in the preferences file (I verified this by moving them
around).
> If that works, that provides evidence it is as I feared. Having any package-
> name match in any specific-form prevents application of all general-form to
> packages with that name. I think that is one valid interpretation of the
No, if you set a different priority, it works as expected.
And, anyway, it can determine the priority all it wants - it's still 750.
Once we've established priorities for all the versions, the doc says:
o If two or more versions have the same priority, install the most
recent one (that is, the one with the higher version number).
I guess I've got a bug.
John
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110330211220.ga27...@cs.brown.edu
Re: apt pinning question
On 2011-03-30 15:00:45 John Bazik wrote:
>My local archive is oldstable (same as lenny), and I have no target
>release defined.
>
>sources.list:
> deb http://mymirror/debian lenny main contrib non-free
> deb http://mymirror/debian-security lenny/updates main contrib non-free
> deb http://mymirror/debian-backports lenny-backports main contrib non
> deb http://mymirror/debian-browncs lenny local
>
>preferences:
> Package: *
> Pin: release a=oldstable
> Pin-Priority: 750
>
> Package: *
> Pin: release a=lenny-backports
> Pin-Priority: 80
>
> Package: dovecot-imapd
> Pin: release a=lenny-backports
> Pin-Priority: 750
>
>% apt-cache policy dovecot-imapd
>dovecot-imapd:
> Installed: (none)
> Candidate: 1:1.2.15-1~bpo50+1
> Package pin: 1:1.2.15-1~bpo50+1
> Version table:
> 1:1.2.15-1~bpo50+1+browncs 750
>750 http://mymirror lenny/local Packages
> 1:1.2.15-1~bpo50+1 750
> 80 http://mymirror lenny-backports/main Packages
> 1:1.0.15-2.3+lenny1 750
>750 http://mymirror lenny/main Packages
>750 http://mymirror lenny/updates/main Packages
>
>The priorities are equal, but the older version from lenny-backports
>is the candidate. I would expect the newer version to be installed.
>
>This looks broken to me.
Looks broken to me, as well. Perhaps this is worth a bug report? At the very
least the output is confusing.
Nothing in /etc/apt/preferences.d? What's the output of (apt-cache policy |
awk 'BEGIN { p = 0 } /^Pinned packages:/ { p = 1 } { if (p) print }')?
I'm thinking that, despite the output, that the "general-form" Pins are not
actually being applied to the "dovecore-impad" package (independent of
version), since a "specific-form" pins matched the package name. Because of
that, the internal (and not displayed!) priority for dovecot-
imapd_1:1.2.15-1~bpo50+1+browncs is actually 500.
(I've always been a bit irked at how priorities are displayed.)
Try adding this to your preferences:
Package: dovecot-imapd
Pin: release a=oldstable
Pin-Priority: 750
If that works, that provides evidence it is as I feared. Having any package-
name match in any specific-form prevents application of all general-form to
packages with that name. I think that is one valid interpretation of the
documentation:
"If any specific-form records match an available package version then the
first such record determines the priority of the package version. Failing
that, if any general-form records match an available package version then the
first such record determines the priority of the package version." -- (man 5
apt_preferences)
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: Re: Re: apt pinning question
> I wonder if it'll behave any differently if you use aptitude instead of
> apt-get.
I've never used aptitude before, so after your suggestion I gave it a
try and aptitude does behave differently.
What it does is it complains of the same problem as apt, then it
offers to fix it and in every example I've tried so far its fix is
exactly what I want.
I'm an instant fan.
Hugin on my current system makes a good example.
"apt-get install hugin -t lucid" wants to install 27 packages, all
from Lucid(testing), most of them libraries.
"apt-get install hugin/lucid" complains that hugin has unmet dependencies
"aptitude install hugin/lucid" does this:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Initializing package states... Done
The following packages are BROKEN:
hugin
The following NEW packages will be installed:
autopano-sift{a} binfmt-support{a} cli-common{a} enblend{a}
enfuse{a} freeglut3{a} libboost-thread1.38.0{a} libgdiplus{a}
libglade2.0-cil{a}
libglib2.0-cil{a} libgtk2.0-cil{a} libimage-exiftool-perl{a}
libmono-cairo2.0-cil{a} libmono-corlib2.0-cil{a}
libmono-i18n-west2.0-cil{a}
libmono-security2.0-cil{a} libmono-sharpzip2.84-cil{a}
libmono-system2.0-cil{a} libpano13-1{a} libplot2c2{a} mono-2.0-gac{a}
mono-gac{a}
mono-runtime{a}
0 packages upgraded, 24 newly installed, 0 to remove and 0 not upgraded.
Need to get 11.6MB of archives. After unpacking 37.1MB will be used.
The following packages have unmet dependencies:
hugin: Depends: hugin-tools (= 2009.2.0+dfsg-2ubuntu1) but it is not
installable
The following actions will resolve these dependencies:
Install the following packages:
hugin-data [2009.2.0+dfsg-2ubuntu1 (lucid)]
hugin-tools [2009.2.0+dfsg-2ubuntu1 (lucid)]
libpano13-bin [2.9.14-2 (karmic, lucid)]
Score is -17
Accept this solution? [Y/n/q/?]
G
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: apt pinning question
On Sat,12.Dec.09, 22:09:59, Rob Owens wrote: > On Sun, Dec 13, 2009 at 09:49:22AM +1100, Gordon Wrigley wrote: > > Another way to look at this would be to ask... > > > > Given two available versions of a package where the higher version has > > the lower priority, how do I get apt to automatically install the > > lower priority one when the higher version is required to meet a > > dependency? > > > If the higher version is required to meet a dependency, why don't you > want it installed? Apt is going to try to meet the dependency. What if *both* version satisfy the dependency? Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Re: apt pinning question
On Sun, Dec 13, 2009 at 03:57:27PM +1100, Gordon Wrigley wrote: > >> Another way to look at this would be to ask... > >> > >> Given two available versions of a package where the higher version has > >> the lower priority, how do I get apt to automatically install the > >> lower priority one when the higher version is required to meet a > >> dependency? > > > > If the higher version is required to meet a dependency, why don't you > > want it installed? > > Sorry I wasn't clear enough with priority and version, an example might help. > > Imagine we are trying to install package Bob from testing with > "apt-get install bob/testing". > Package Bob depends on package Fred with version >= 1.1 > > We have these two candidates for package Fred: > stable, priority 500, version 1.0 > testing, priority 400, version 1.1 > > And Apt says: > > The following packages have unmet dependencies: > bob: Depends: fred but it is not going to be installed > > As I understand it this is because it chose the priority 500 version > which isn't sufficient to meet the dependency. > That is the way the docs say it should work, if I understand correctly. apt-get install bob/testing means to install "bob" from testing, but do not install any dependencies from testing -- try to meet dependencies from the highest pin priority. "apt-get install -t testing bob" means to install "bob" from testing, and install any dependencies from testing as well. Suppose "bob" also depends on "sam" (any version), and "sam" is in both the stable and testing repos. I don't think there is an automated way to apt-get install bob, while pulling in "sam" from stable and "fred" from testing. Somebody correct me if I'm wrong. > > Apt is going to try to meet the dependency. > > I wish it would, but it doesn't and I can't figure out what I'm doing wrong. > As far as I can see it ALWAYS goes for the the higher priority version > even if that won't meet the dependency. > "apt-get install -t testing bob" would work on my Debian Lenny system. However, I don't have stable and testing pinned in preferences. I have in my apt.conf: APT::Default-Release "stable"; This effectively pins stable to 990. I also tend to use aptitude. I wonder if it'll behave any differently if you use aptitude instead of apt-get. In case you're not aware, "man apt_preferences" is where you can find a lot of info on pinning and priorities. -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Re: apt pinning question
>> Another way to look at this would be to ask... >> >> Given two available versions of a package where the higher version has >> the lower priority, how do I get apt to automatically install the >> lower priority one when the higher version is required to meet a >> dependency? > > If the higher version is required to meet a dependency, why don't you > want it installed? Sorry I wasn't clear enough with priority and version, an example might help. Imagine we are trying to install package Bob from testing with "apt-get install bob/testing". Package Bob depends on package Fred with version >= 1.1 We have these two candidates for package Fred: stable, priority 500, version 1.0 testing, priority 400, version 1.1 And Apt says: The following packages have unmet dependencies: bob: Depends: fred but it is not going to be installed As I understand it this is because it chose the priority 500 version which isn't sufficient to meet the dependency. > Apt is going to try to meet the dependency. I wish it would, but it doesn't and I can't figure out what I'm doing wrong. As far as I can see it ALWAYS goes for the the higher priority version even if that won't meet the dependency. G -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: apt pinning question
On Sun, Dec 13, 2009 at 09:49:22AM +1100, Gordon Wrigley wrote: > Another way to look at this would be to ask... > > Given two available versions of a package where the higher version has > the lower priority, how do I get apt to automatically install the > lower priority one when the higher version is required to meet a > dependency? > If the higher version is required to meet a dependency, why don't you want it installed? Apt is going to try to meet the dependency. If you think the lower version should satisfy the dependency, but the packager didn't agree, you can try editing the control file of the package. You'll have to download the package, open it with an archiver program (I use file roller), then open control.tar.gz. That will contain a file called "control". Edit that and you can change the "Depends" line. -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: apt pinning question
Another way to look at this would be to ask... Given two available versions of a package where the higher version has the lower priority, how do I get apt to automatically install the lower priority one when the higher version is required to meet a dependency? G -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Re: apt pinning question
> Are you sure that this applies to *all* lucid sections, including > lucid-updates and lucid-security? I recall reading some blogs that > indicated that Ubuntu's pinning and default release settings don't > work exactly like Debian's. I checked it with apt-cache policy and everything karmic is 500 and everything lucid is 400. G -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: apt pinning question
On Sat, Dec 12, 2009 at 03:28:19PM +1100, Gordon Wrigley wrote: > I wasn't sure what venue was best to ask this in, so if this is the > wrong place please direct me to the correct place. > > I'm using APT pinning to pull packages from both Ubuntu Karmic(stable) > and Ubuntu Lucid(testing) but I'm having problems getting APT to > produce the behavior I want. > > What I want it to do is generally get packages from Karmic(stable). > Except when I explicitly specify that I want something from > Lucid(testing), at which point I want it to meet as much of the > dependencies as it can from Karmic(stable) but where the > Karmic(stable) packages aren't new enough it should get them from > Lucid(testing). > > I've tried several different configurations but none of them seem to > work. Currently I have Lucid(testing) pinned at 400 with > > Package: * > Pin: release lucid > Pin-Priority: 400 > Are you sure that this applies to *all* lucid sections, including lucid-updates and lucid-security? I recall reading some blogs that indicated that Ubuntu's pinning and default release settings don't work exactly like Debian's. -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: apt pinning question
On Sat,12.Dec.09, 15:28:19, Gordon Wrigley wrote: > I wasn't sure what venue was best to ask this in, so if this is the > wrong place please direct me to the correct place. Hmm, I would suggest ubuntu-users or similar mailing list, but there is indeed a chance that your question is not Ubuntu specific... [snip] > 1: sudo apt-get install firefox-3.5/lucid > > This will only pull dependencies from Karmic(stable) and will > generally fail because some supporting package doesn't have a high > enough version in Karmic(stable). > Now of course I could go through recursively by hand and resolve every > unmet dependency, but that quickly gets very tedious. > > 2: sudo apt-get install firefox-3.5 -t lucid In all Debian docs I have seen this is the recommended way of pulling specific packages from a non-default repository. > This will pull all required dependencies from Lucid(testing). Even > those that could have been met from Karmic(stable), which > unnecessarily pollutes my system with Lucid(testing) packages. > > What am I missing here? Assuming your apt behaves the same as Debian I think you want to set lucid to something smaller than 100, see apt_preferences(5) for more info. > P.S. I'm not subscribed to the list, it'd be handy if people could CC > me on any replies but I intend to keep an eye on the list archive > anyway. Sure ;) Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
