[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#554773: cupt: Wrong computation of preferences/pinning



(i guess we simply have a different understanding of version in
 this context and therefore different behavior in apt vs. cupt)

2009/11/23 Eugene V. Lyubimkin <jackyf.devel@gmail.com>:
>> - one for each origin/release/distribution (e.g. sid or "")
> I don't understand this one. And anyway it isn't stated anywhere, so it
> doesn't count.
In "The Effect of APT Preferences" it is said:
> The general form assigns a priority to all of the package versions
> in a given distribution (that is, to all the versions of packages that
> are listed in a certain Release file) or to all of the package versions
> coming from a particular Internet site, as identified by the site´s fully
> qualified domain name.
(I have quoted the first few words already in my first mail)
So why it is not stated somewhere and therefore doesn't count?
The versions from a different distribution/origin doesn't have a pin
assigned yet, so another pin-setting can match them.

> So I don't get your point. Again: "Failing that, if any
> general-form records match an available package version then the first such
> record determines the priority of the package version", and cupt do exactly that.
Okay, i though it is already clear from the two quotes in my first mail,
but to say it directly: (In my understanding) apt handles a package
version as a triple of (package, number, origin)
[while it couples a version than (package, number, checksum) is identical in
 the output and while downloading - apt does this to handle cases then two
 archives provide the same version number but with different checksums ]
A "general-form" does match against the third or against the second column,
a specific additional against the package name. If this would be not the case,
why displaying the pin for each origin separately in the first place,
two calculated pins for the first matching version-specific and the first
matching origin-specific would be enough in that case?

> I definitely will not accept bug reports based on points like 'do what I mean,
> not what I say'.
I personally think that it is said in the bugreport pin file that i want
to pin packages from unstable to X and packages from testing to Y and
that a packages belonging to both should get both, resulting in max(X,Y)
in most cases (e.g. not in the -1 case) and not always X.

(The stanza you quote applies for me only if e.g. both settings
would specify unstable with different pin-priorities.)


Best regards / Mit freundlichen Grüßen,

David "DonKult" Kalnischkies



Reply to: