Re: apt-pinning, strange behavior
On 10/10/13 22:06, Dmitrii Kashin wrote: berenger.mo...@neutralite.org writes: In the same priority range, the package which will be installed is the one with the highest priority, so it is fine to have one set of package with 500 ( or I could take 600 or any other value ) for low priority, and the other at 900 ( or 800 or... ), so that the version with 900 will be installed against the lower one, even if the lower one is more recent. Oh... Truely? I thought differently and was sure I am right. I just skimmed again through apt_preferences man page, but did not find such examples or explanations. Where's it documented? For reference, the section in apt_preferences(5) that documents this is: APT then applies the following rules, listed in order of precedence, to determine which version of a package to install. · Never downgrade unless the priority of an available version exceeds 1000. (Downgrading is installing a less recent version of a package in place of a more recent version. Note that none of APT's default priorities exceeds 1000; such high priorities can only be set in the preferences file. Note also that downgrading a package can be risky.) · Install the highest priority version. · If two or more versions have the same priority, install the most recent one (that is, the one with the higher version number). · If two or more versions have the same priority and version number but either the packages differ in some of their metadata or the --reinstall option is given, install the uninstalled one. As you can see, it uses the priority first, and then the version number. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53107035.1040...@zoho.com
Re: apt-pinning, strange behavior
berenger.mo...@neutralite.org writes: Le 10.10.2013 23:06, Dmitrii Kashin a écrit : berenger.mo...@neutralite.org writes: In the same priority range, the package which will be installed is the one with the highest priority, so it is fine to have one set of package with 500 ( or I could take 600 or any other value ) for low priority, and the other at 900 ( or 800 or... ), so that the version with 900 will be installed against the lower one, even if the lower one is more recent. Oh... Truely? I thought differently and was sure I am right. Maybe you are right, but in that case, how would you explain the behavior I had if a package of a priority of 500 is considered to have the same priority as a package with 900 ? ;) My opinion was that priorities are used to determine which package of equal versions should be installed. And there is not difference if packages have different versions: only one with a higher version will be installed. Exception is different priority range for theese packages. But truely, in this case why do we have such a wide range of priorities? So I'm inclined to agree with you. I just skimmed again through apt_preferences man page, but did not find such examples or explanations. Where's it documented? I must admit, that I only base my words on old readings and experimentations. It also seems logic: what would be the interest to have so wide ranges of numbers oterwise? Yes-yes-yes. This thought visited my mind too. Maybe I'm wrong, but what I have seen those days tends to prove that I am not. I think you are right too, but it will be well to find where this behavior is correctly described. Unfortunately I have not seen good preferences documentation at the current time. pgpZj47UatBfq.pgp Description: PGP signature
Re: apt-pinning, strange behavior
Le 09.10.2013 19:28, Dmitrii Kashin a écrit : berenger.mo...@neutralite.org writes: Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Certainly it wants. According to apt_preferences(5): Yes, it wants, because I did not specified the priority for the release stable-updates. This is what apt-cache policy pointed, and once fixed, my problem disappeared, and I finally understood that obvious issue. You should use priority of =990 for the target release. In the same priority range, the package which will be installed is the one with the highest priority, so it is fine to have one set of package with 500 ( or I could take 600 or any other value ) for low priority, and the other at 900 ( or 800 or... ), so that the version with 900 will be installed against the lower one, even if the lower one is more recent. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? You have just set this priority to the whole stable repository. This should not work at all. Maybe it will be sane to show us how you set pins? Here are the 2 versions, first the one which really works ( in the hope I did not forget something, since I have enabled stable-updates, stable/updates, stable and testing. So I am not sure about the stable/updates one. Not used to stable.): Package: * Pin: release a=stable Pin-Priority: 800 Package: * Pin: release a=stable-updates Pin-Priority: 900 Package: * Pin: release a=testing Pin-Priority: 500 Package: i3-wm i3 Pin: release a=testing Pin-Priority: 900 #i3 dependencies Package: gir1.2-glib-2.0 libc-dev-bin libc6 libc6-dev libgirepository-1.0-1 libglib2.0-0 libpango1.0-0 locales python-gi Pin: release a=testing Pin-Priority: 900 Package: clang Pin: release a=testing Pin-Priority: 900 #clang dependencies Package: libclang-common-dev libgcc1 libgomp1 libitm1 libquadmath0 libstdc++6 libobjc4 Pin: release a=testing Pin-Priority: 900 The one which with tzdata updated to testing: Package: * Pin: release a=stable Pin-Priority: 900 Package: * Pin: release a=testing Pin-Priority: 500 Package: i3-wm i3 Pin: release a=testing Pin-Priority: 900 #i3 dependencies Package: gir1.2-glib-2.0 libc-dev-bin libc6 libc6-dev libgirepository-1.0-1 libglib2.0-0 libpango1.0-0 locales python-gi Pin: release a=testing Pin-Priority: 900 Package: clang Pin: release a=testing Pin-Priority: 900 #clang dependencies Package: libclang-common-dev libgcc1 libgomp1 libitm1 libquadmath0 libstdc++6 libobjc4 Pin: release a=testing Pin-Priority: 900 PS: I think I should probably send the package-specific priorities and their dependencies into specific files in preferences.d/ but I'll do that when I'll have a real lot of packages that I need updated. 2 packages ( 3 in fact, I do not show opera here, to stay with the original situation ) can be kept in one file without making it unmaintainable. -- 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/4dff77b2e59cff8911bd3f6c405f5...@neutralite.org
Re: apt-pinning, strange behavior
berenger.mo...@neutralite.org writes: In the same priority range, the package which will be installed is the one with the highest priority, so it is fine to have one set of package with 500 ( or I could take 600 or any other value ) for low priority, and the other at 900 ( or 800 or... ), so that the version with 900 will be installed against the lower one, even if the lower one is more recent. Oh... Truely? I thought differently and was sure I am right. I just skimmed again through apt_preferences man page, but did not find such examples or explanations. Where's it documented? Yes, it wants, because I did not specified the priority for the release stable-updates. This is what apt-cache policy pointed, and once fixed, my problem disappeared, and I finally understood that obvious issue. Glad for you. PS: I think I should probably send the package-specific priorities and their dependencies into specific files in preferences.d/ Yes, it's a good practice. I do so. But mostly in order to set negative priorities. pgpPtARO8Mur6.pgp Description: PGP signature
Re: apt-pinning, strange behavior
Le 10.10.2013 23:06, Dmitrii Kashin a écrit : berenger.mo...@neutralite.org writes: In the same priority range, the package which will be installed is the one with the highest priority, so it is fine to have one set of package with 500 ( or I could take 600 or any other value ) for low priority, and the other at 900 ( or 800 or... ), so that the version with 900 will be installed against the lower one, even if the lower one is more recent. Oh... Truely? I thought differently and was sure I am right. Maybe you are right, but in that case, how would you explain the behavior I had if a package of a priority of 500 is considered to have the same priority as a package with 900 ? ;) I just skimmed again through apt_preferences man page, but did not find such examples or explanations. Where's it documented? I must admit, that I only base my words on old readings and experimentations. It also seems logic: what would be the interest to have so wide ranges of numbers oterwise? Maybe I'm wrong, but what I have seen those days tends to prove that I am not. -- 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/85a4a2725fc50736dcf02195d33b1...@neutralite.org
Re: apt-pinning, strange behavior
On Wed, 09 Oct 2013 00:12:46 +0200 berenger.mo...@neutralite.org wrote: Le 08.10.2013 22:42, Sven Joachim a écrit : On 2013-10-08 19:06 +0200, berenger.mo...@neutralite.org wrote: Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? I don't know either, but apt-cache policy tzdata should explain it. Cheers, Sven Thanks for the hint, I had forgotten about apt-cache policy. I finally understood, why the update was on the run: tzdata: Installé : 2013d-0wheezy1 Candidat : 2013d-1 Table de version : 2013d-1 0 500 http://ftp2.fr.debian.org/debian/ testing/main amd64 Packages *** 2013d-0wheezy1 0 500 http://ftp2.fr.debian.org/debian/ stable-updates/main amd64 Packages 100 /var/lib/dpkg/status 2013c-0wheezy1 0 900 http://ftp2.fr.debian.org/debian/ stable/main amd64 Packages Version 2013d-0wheezy1 had the same priority as testing one so testing was installed because more recent. Now, I wonder why I have 3 versions of that package listed when I only have 2 sources enabled? Could it be because of stable, stable/updates and stable-updates repositories? ( I am not used to stable, so I do not have the updates repos usually ) And also why I have a wheezy version with a priority of 500... I can not even find the 2013d-0wheezy1 in debian packages... The answer to your question is in files /var/lib/apt/lists/*_Release. You can notice the difference: Suite: stable Suite: stable-updates -- 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/20131009111749.45e87...@eunet.rs
Re: apt-pinning, strange behavior
Le 09.10.2013 11:17, Marko Randjelovic a écrit : On Wed, 09 Oct 2013 00:12:46 +0200 berenger.mo...@neutralite.org wrote: Le 08.10.2013 22:42, Sven Joachim a écrit : On 2013-10-08 19:06 +0200, berenger.mo...@neutralite.org wrote: Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? I don't know either, but apt-cache policy tzdata should explain it. Cheers, Sven Thanks for the hint, I had forgotten about apt-cache policy. I finally understood, why the update was on the run: tzdata: Installé : 2013d-0wheezy1 Candidat : 2013d-1 Table de version : 2013d-1 0 500 http://ftp2.fr.debian.org/debian/ testing/main amd64 Packages *** 2013d-0wheezy1 0 500 http://ftp2.fr.debian.org/debian/ stable-updates/main amd64 Packages 100 /var/lib/dpkg/status 2013c-0wheezy1 0 900 http://ftp2.fr.debian.org/debian/ stable/main amd64 Packages Version 2013d-0wheezy1 had the same priority as testing one so testing was installed because more recent. Now, I wonder why I have 3 versions of that package listed when I only have 2 sources enabled? Could it be because of stable, stable/updates and stable-updates repositories? ( I am not used to stable, so I do not have the updates repos usually ) And also why I have a wheezy version with a priority of 500... I can not even find the 2013d-0wheezy1 in debian packages... The answer to your question is in files /var/lib/apt/lists/*_Release. You can notice the difference: Suite: stable Suite: stable-updates Thanks. I did not thought that it would be considered as a different repo, which is absent from http://packages.debian.org but it explains the behavior I have. -- 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/1a5f89a7d2f551b1158e86eecc6df...@neutralite.org
Re: apt-pinning, strange behavior
berenger.mo...@neutralite.org writes: Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Certainly it wants. According to apt_preferences(5): 500 = P 990 causes a version to be installed unless there is a version available belonging to the target release or the installed version is more recent As you see, both pins are in the same range, so there are managed by the same rules. You should use priority of =990 for the target release. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? You have just set this priority to the whole stable repository. This should not work at all. Maybe it will be sane to show us how you set pins? pgpLgC4869UAx.pgp Description: PGP signature
apt-pinning, strange behavior
Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? -- 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/28f8d241e1c1bcf2f24cb2073969d...@neutralite.org
Re: apt-pinning, strange behavior
On 2013-10-08 19:06 +0200, berenger.mo...@neutralite.org wrote: Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? I don't know either, but apt-cache policy tzdata should explain it. Cheers, Sven -- 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/878uy3o5p3@turtle.gmx.de
Re: apt-pinning, strange behavior
Le 08.10.2013 22:42, Sven Joachim a écrit : On 2013-10-08 19:06 +0200, berenger.mo...@neutralite.org wrote: Since I had to reinstall from my last kernel error, I decided to stay with stable on that computer, but I need some softwares in less outdated versions, like development libraries or i3 ( this one is not a need but a question of comfort, I admit ), so I want to use apt-pining. I have set all packages from stable to a priority of 900 and testing packages with 500. But tzdata wants to upgrade, for an unknown reason. Explicitly making it to a priority of 900 for stable fixes that, but I can not understand why it is needed? I don't know either, but apt-cache policy tzdata should explain it. Cheers, Sven Thanks for the hint, I had forgotten about apt-cache policy. I finally understood, why the update was on the run: tzdata: Installé : 2013d-0wheezy1 Candidat : 2013d-1 Table de version : 2013d-1 0 500 http://ftp2.fr.debian.org/debian/ testing/main amd64 Packages *** 2013d-0wheezy1 0 500 http://ftp2.fr.debian.org/debian/ stable-updates/main amd64 Packages 100 /var/lib/dpkg/status 2013c-0wheezy1 0 900 http://ftp2.fr.debian.org/debian/ stable/main amd64 Packages Version 2013d-0wheezy1 had the same priority as testing one so testing was installed because more recent. Now, I wonder why I have 3 versions of that package listed when I only have 2 sources enabled? Could it be because of stable, stable/updates and stable-updates repositories? ( I am not used to stable, so I do not have the updates repos usually ) And also why I have a wheezy version with a priority of 500... I can not even find the 2013d-0wheezy1 in debian packages... -- 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/9dc2fe2bca18a98dd48abc1de5313...@neutralite.org
