and happy new year to you all..

Recently I've built nginx deb package v1.4.4 from debian backport source that of course I've added to the apt sources.list and things went great.

I have run apt-get update then apt-get -V upgrade today to check how debian 7 apt would behave.. and this is what I got:

root@debian-lab:~/nginx-1.4.4-packages# apt-get -V upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
   nginx-full (1.4.4-1~bpo70+1 => 1.4.4-1~bpo70+1)
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/464 kB of archives.
After this operation, 9,027 kB disk space will be freed.
Do you want to continue [Y/n]?

As you can see, apt is trying to upgrade from (1.4.4-1~bpo70+1 => 1.4.4-1~bpo70+1), which is basically two identical version but my installed deb package has custom nginx modules added to default nginx-full and after the update, my custom modules are all gone and replaced by the standard debian wheezy backport deb.. I've built my nginx backport deb package from debian backport source and installed build-deb through the backport as well but some dependencies installed automatically from the stable that's what I saw from the verbose output..

Can you please help me to prevent this with an example? I heard about pinning, but is it the answer to my problem?


I've tried to apt pin the package and didn't work and here is the output i got:

apt-cache policy nginx-full
Installed: 1.4.4-1~bpo70+1
Candidate: 1.4.4-1~bpo70+1
Version table:
 1.4.4-1~bpo70+1 0
    100 http://ftp.uk.debian.org/debian/ wheezy-backports/main amd64 Packages
*** 1.4.4-1~bpo70+1 0
    100 /var/lib/dpkg/status
 1.2.1-2.2+wheezy2 0
    500 http://ftp.uk.debian.org/debian/ wheezy/main amd64 Packages
    500 http://security.debian.org/ wheezy/updates/main amd64 Packages

And the following is the apt-cache policy nginx:

/etc/apt/preferences.d# apt-cache policy nginx
  Installed: 1.4.4-1~bpo70+1
  Candidate: 1.4.4-1~bpo70+1
  Package pin: 1.4.4-1~bpo70+1
  Version table:
 *** 1.4.4-1~bpo70+1 1001
        100 http://ftp.uk.debian.org/debian/ wheezy-backports/main amd64 Packages
        100 /var/lib/dpkg/status
     1.2.1-2.2+wheezy2 1001
        500 http://ftp.uk.debian.org/debian/ wheezy/main amd64 Packages
        500 http://security.debian.org/ wheezy/updates/main amd64 Packages

But still apt is trying to upgrade and replace it!!

Sources.list content:

deb http://ftp.uk.debian.org/debian/ wheezy main
deb-src http://ftp.uk.debian.org/debian/ wheezy main

deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main

# wheezy-updates, previously known as 'volatile'
deb http://ftp.uk.debian.org/debian/ wheezy-updates main
deb-src http://ftp.uk.debian.org/debian/ wheezy-updates main

# Wheezy Backports repository
deb http://ftp.uk.debian.org/debian wheezy-backports main
deb-src http://ftp.uk.debian.org/debian wheezy-backports main

I've tried to apt pin once the package name 'nginx' and another time with nginx-full..

But both fail to hold the package!!!

  • cat /etc/apt/sources.list? – strugee Dec 31 '13 at 5:11
  • deb ftp.uk.debian.org/debian wheezy main contrib non-free deb-src ftp.uk.debian.org/debian wheezy main contrib non-free deb security.debian.org wheezy/updates main contrib non-free # Wheezy Backports repository deb ftp.uk.debian.org/debian wheezy-backports main deb-src ftp.uk.debian.org/debian wheezy-backports main – Dr.SMS Dec 31 '13 at 5:39
  • please edit your question to include this information. doing so in comments means that the information is not only badly formatted, but might disappear later. – strugee Dec 31 '13 at 7:20
  • Ok,, thanks.. Any ideas though?? – Dr.SMS Dec 31 '13 at 7:21
  • maybe. I need the contents of sources.list, though, and frankly, I don't want to figure out what's what in that comment. – strugee Dec 31 '13 at 7:26

To avoid problems, first, I would suggest you to use a custom (and greater) version number for your custom package, for example : 1.4.4-1~bpo70+1-mrsms. This would only be fair because your package is not the same exact version as the "official" backport. You can change the version number from the file debian/changelog before you build it.

You can test version comparison with dpkg (here, gt stands for "greater than", the return code is 0 if the expression is true):

$ dpkg --compare-versions 1.4.4-1~bpo70+1-mrsms gt 1.4.4-1~bpo70+1
$ echo $?

Be careful because your custom package will still be upgraded if an even greater version is found on the online repository. I would then suggest you to use pinning to avoid that (see man apt_preferences).

You may try this by creating a file, say /etc/apt/preferences.d/nginx-full, with this content:

Package: nginx-full
Pin: version 1.4.4-1~bpo70+1-mrsms
Pin-Priority: 1001

You can also hold the package in it's current installed state, that's very effectual, but not very elegant (might trouble future upgrades):

# aptitude hold nginx-full
# echo "nginx-full" hold |dpkg --set-selections
  • Thanks,, but someone suggested i use: Package: nginx Pin: version 1.4.4-1~bpo70+1 Pin-Priority: 1001 ,, but it's not working.. I don't use aptitude only apt-get.. I tried to build the package with fake high version like 1.7.7 which is very unlikely to be released anytime soon.. Does it really matter what number I put in debian/changelog version? is it in anyway dangerous? and then what about security updates in the future? BTW, I've build the nginx backport package with some build dependencies from backport repository by running apt-get -t wheezy-backports build-dep nginx.. – Dr.SMS Dec 31 '13 at 14:33
  • It is worth noting that apt-pinning is buggy insofar as apt-get and aptitude don't necessarily respect each other's pins/holds. I forget the details; I just use apt-get. I second the recommendation for increasing the version number. This will of course mean that you don't get security upgrades automatically, but this is inevitable with a custom package; you can't have everything. – Faheem Mitha Dec 31 '13 at 14:45
  • @FaheemMitha I agree about holds (that's why I use 2 different commands to hold). However, I didn't know about pinning. Is there an open bug report for this? – Totor Jan 2 '14 at 23:31
  • @Totor I think I may be mistaken about apt pinning. I think I was confusing it with holds. – Faheem Mitha Jan 2 '14 at 23:33
  • @Dr.SMS If you're pinning on the version number, of course it didn't change anything since both packages shared the same. You should try pinning on "origin" or some other relevant criterion. Personally, I wouldn't have used a fake version number because it could be misleading. It is not "dangerous", but it might get slightly tricky if you want to go back to the official release one day or if you upgrade your distribution. As FaheemMitha pointed out, you loose the benefit of security update because you become the maintainer of your own package, hence you must recompile to stay secure... :) – Totor Jan 2 '14 at 23:47

In chat, OP stated that he installed his package with dpkg --install. Additionally, IIRC, APT parses which package it prefers in the following way:

  1. If a package is pinned, don't do anything with it.
  2. Prefer whichever package known to the system has the highest program version.
  3. If there are conflicts, prefer whichever package known to the system has the highest package version.
  4. If there are still conflicts, prefer packages from a repository listed in /etc/apt/sources.list.
  5. If there are still conflicts, prefer a package from whichever repository comes first in sources.list.

Armed with this information, we can posit that APT is choosing the repository version over the locally installed version at step 4. So, there are four ways to solve this problem:

  1. Increase the package version to something beyond what the official Debian repositories provide. This will cause your locally installed package to be selected over the Debian package during step 3. (@Totor beat me to it, so I'll defer to his answer for instructions on how to do this.)
  2. Increase the program version to something beyond what the official Debian repositories provide. This will get your package selected during step 2, but I would highly recommend not doing this and instead incrementing the package version - there's no technical reason, it's just more correct. However, if you do choose to do it this way, it is done in basically the same way as the package version, except that you change a different field in your debian/control file (or whatever else you are using to generate your package).
  3. Pin your package. This will cause your package to be selected during step 1. Again, this is covered in @Totor's answer.
  4. Create a local repository, put your package in it, and ensure that when you add it to your sources.list, it comes before the official Debian repositories. This will trigger a selection in step 5. In order to do this, refer to this Debian Wiki page. You may also be interested in this Ask Ubuntu question, if you want an easier tutorial-style reference.
  • why do you not recommend changing the program version? I changed it yesterday to 1.5.5 and it worked.. and I've changed it from the changelog file.. so what about this debian/control file that you are talking about?? – Dr.SMS Jan 1 '14 at 19:45
  • @Dr.SMS you too! I'll add some links and explanations – strugee Jan 2 '14 at 0:10
  • so far I've installed devscripts in order to use dch command but still I haven't found a good tutorial about its usage and also I noticed that you guys never mentioned anything about dch.. So what do you say about using dch -v which the help page says: Add a new changelog entry with version number specified – Dr.SMS Jan 2 '14 at 0:16
  • @Dr.SMS honestly, I'm not sure because I haven't done a ton of work with Debian packaging tools (only the basics). I edited the answer, though, to hopefully clear up some confusion – strugee Jan 2 '14 at 0:33
  • I guess you are wrong about the control file.. it has no version numbers or anything.. I'm just gonna try the changelog file since most of articles out there say that its first line is what determines the package release and version numbers and I guess they are right because I've tried it once and it worked. So I guess it's better to delete that part in your answer.. Ciao! – Dr.SMS Jan 2 '14 at 0:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.