This is a place where I've always found the documentation lacking. I pretty much only learned how this works by looking at how it is done in other packages. As with most things in Debian packaging, there are a few ways to do this. I find the simplest way is to use debian/package.install
files. Here's an example of a package I've worked on, imagination (bzr branch).
First, we need to create the package in debian/control
. There are three stanzas now. One for the source package and one for each binary package. Note that the foo-data package should be Architecture: all
. Also note that imagination Depends on imagination-common (= ${source:Version})
.
Next, we create a debian/imagination.install
file. This contains the specific files or paths which we want to end up in the imagination package. For this package we want all the architecture dependent files. The desktop file is included as it needs to say with the binary that it calls in its Exec:
line.
usr/bin/
usr/lib/
/usr/share/applications/imagination.desktop
We need to create a debian/imagination-common.install
file. This will contain all of the architecture independent files, images, translations, docs, and the like.
/usr/share/doc/
/usr/share/icons/
/usr/share/imagination/
/usr/share/locale/
man dh_install
describes what's actually going on here:
maybe you have a large package that
builds multiple binary packages. You
can use the upstream Makefile to
install it all into debian/tmp, and
then use dh_install to copy
directories and files from there into
the proper package build directories.
What it means by "the proper package build directories" is that by the end of the build process, everything that will be in the resulting foo.deb
will be found in src/debian/foo
. The files that will end up in foo-data.deb
will be found in src/debian/foo-data
. As debian/rules
is essentially just a Makefile, you can begin to imagine so other ways of getting the same result.
You're mixing two different distributions' packages together. For various reasons, this is a bad idea:
Security.
Stability.
Conflicting updates, which you have right now.
If you let above updates go through, you encounter the first two problems, and then you're in deep trouble if say, as an example a kernel update comes through!
Also, this makes getting an accurate bug report or stacktrace almost impossible, if not entirely impossible.
In short, if you need Debian sid, run sid. Otherwise, run Ubuntu, and just add newer software you want to via a PPA or backports.
More explanations here:
Best Answer
There are several questions which I will answer individually:
How to download (and not install) individual binary package?
apt-get
has an option to only download the package:You will find the downloaded package in
/var/cache/apt/archives/
. In this case you will have to add a new sources list configuration to apt.How to download individual source package?
or when you know the location of the .dsc file:
Both approaches do verify the signature on the files
How to pin the sources.list aka how do I not mess my installation?
You have already pointed to the page of basic description for APT Pinning, and I would only add that you probably want to read the apt_preferences manpage which also have nice examples to accomplish things you need. Especially see the section 'Tracking Stable' in EXAMPLES, since it describes something very close to your needs:
There's an usefull command when playing with multiple sources and APT Pinning:
This shows that the installed version is 1.1.3-1~bpo60+1, and candidate is 1.2.0~rc3-1~bpo60+1, which will get installed on next
apt-get upgrade
. Also there's some older version available from yet another repository.How to download Debian archive key?
Debian archive key is published on ftp-master. You will need to import the key into your gpg keyring:
Then you will have to check its signatures:
And track the individual GPG keys to Debian developers either by tracking it manually, or f.e. checking at PGP Key Statistics project. And unless there's a chain from your PGP/GPG key to the Debian key archive, you will have to make a leap of faith at some point of time.
How to download and verify individual packages by hand
So the other approach is more complicated, because deb packages are not signed individually, but only the
Release
file is signed. Thus you will need to download and verify the signature onRelease
andPackages
files together with the individual package.I will add an example that will be clearer.
Imagine you want to download Debian package for Knot DNS from it's official PPA for Ubuntu precise on amd64 architecture.
You will have to click through the directories and find these files:
The next step would be to verify the signature on the
Release
file:Of course you'll need to verify the key in some other means (like the Debian/Ubuntu maintainers key, checking it from launchpad, etc, etc...)
When you have verified the correct signature on
Release
file you can go to next step – verifying the Packages file.As you can see, the signature can be found in the signed
Release
file, thus we have verified the integrity ofPackages
file by computing and comparing its SHA-256 fingerprint.The last step is similar. You need to compute and compare the fingerprint of the individual package:
At this point we have securely chained the package to the signed
Release
file. So if you believe the signature on theRelease
file, you can be sure that the package was downloaded intact.You can read more in Secure APT article at Debian Wiki.