Re: apt_preferences man page
On 11 Dec 2002, Thomas Hood wrote:
> Sending my final draft to Jason Gunthorpe for review...
Looks OK..
The first paragraph: '<para>Several versions of a package' has a bit of a
misleading slant, it's actually possible that a single source can have
multiple version of the package, and that multiple download sites can
exist if the same version of a package is in more than one of
stable,testing,unstable. I occasionaly get confused people mailing me that
APT is dowloading (and thus, they thing it must be using) a package from
unstable, when in fact unstable and testing have the same version for this
package.
The latter part might be clarified slightly with an example from
'apt-cache policy foo' which summarizes all the output into two essential
lines, the 'Installed:' line and the 'Candidate:' line. Subject to
dependency constraints and user selection APT will select one of the two
for installation. I also occasonally get messages from people who are
trying to all-downgrade and don't understand that it is a legitimate
position for APT to 'do nothing' to a package.
Moving on, '# Command to install the <literal/testing/ version' .. I also
get many confused emails about this. -t testing does not *force* testing
to be selected. It means that if upgrading from a version <= testing
select testing, otherwise select the highest available version.
The rest of the document gets that right, but it's probably best to push
the point at the very first time the concept is introduced. The 'Tracking
Testing' section at the bottom is a great addition. You might want to note
that 'apt-get -t unstable install foo' will still correctly override the
preferences file and install those packages from unstable.
A note should be added that downgrading packages technically isn't
supported by the debian project and should be used sparingly.
It may also be worth noting that if two instances have the same version
number they can still be considered to be different if their dependency
lines, installed-size, etc do not match exactly. In this instance APT
always prefers to reinstall the package. This comes up commonly if people
recompile something but do not change the version number.
Have the examples been checked by using apt-cache policy? I"m not sure the
last very complex one is right. I'm also not entirely use the description
of the version'd pin's matches what the code does, though your description
perhaps describes what it should do.
Any reference to a verson number in a release (ie v=3.0) should probably
be considered to be v=3.0*. This is because we now have a release 3.0r1
which doesn't exactly match 3.0 (and yes, this is kind of unfortunate) :|
There is a document called 'files.sgml' in the APT source tree which gives
a description of the release file format. It might help clarify some of
the description of that format.
Jason
Reply to: