Hi Daniel.
On Sat, 2012-03-17 at 12:29 +0800, Daniel Hartwig wrote:
> Like David says, please always modify the version number.
Well I did this, or actually my the whole need for this has vanished in
the meantime ;-)
Nevertheless,... I still think that documentation is ambiguous/incorrect
here... or even more, that handling is incorrect: reinstalls should not
be considered as downgrades...
And so far, no one could show me why I'm wrong with respect to this.
So I guess best would be to reopen this bug and discuss whether a)
behaviour could/should be changed or b) the apt_preferences(5) manpage
could be extended to note that reinstall == downgrade, e.g. from
>· 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.
to
>· Never downgrade (OR REINSTALL) unless the priority of an available
> version exceeds 1000. ("Downgrading" is installing a less recent OR
> THE SAME version of a package in place of ANOTHER version.
(There may be other places in the manpage, where the same information
should be added.)
The above is however probably not enough, as David says,.. the order of
sources.list entries is important... so reinstalling is done if ordered
first but not the other way round.
Effectively this makes this as if priorities were ignored for the same
version (while not the sources.list order), which seems bad to me
anyway.
So perhaps a change in behaviour was the better way :)
> Just consider the smallest possible increments that the Debian package
> would get and pick a version below those:
[snip snap]
> As a final note, if the current Debian version is something like
> 2.3-1+anupdate1 then you should still add to that:
> 2.3-1+anupdate1+~calestyo1
Thanks for your notes on the package versions,.. I've played around with
this myself already and came to more or less the same conclusions than
you (I've just decided to use ~~).
However,... in principle one doesn't know whether this makes you "safe"
because the maintainer/security team could in principle always choose
something that is higher than "their" previous version, but less than
"mine".
Cheers,
Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature