Bug#554773: cupt: Wrong computation of preferences/pinning
>>> My pinnings are as follow : >>> Package: * >>> Pin: release a=unstable >>> Pin-Priority: 100 >>> >> I believe cupt is doing right here. From 'man apt_preferences': And i believe apt-get is right here. ;) From 'man apt_preferences': > If there is no preferences file or if there is no entry in the file that > applies to a particular version then the priority assigned to that > version is the priority of the distribution to which that version belongs. ( First sentence in "APT´s Default Priority Assignments" ) 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 [...] Or in short: A package version has multiply pin-settings: - a version specific one (e.g. 5.8*) - one for each origin/release/distribution (e.g. sid or "") And this is btw what i expect with the given pin-file, but your mileage may vary, of course. (Or to rephrase it: how to get the same behavior in cupt?) I would therefore reassign the bug (again) to cupt and proceed with improving the manpage in #557637 instead, but i don't want to play bug-ping-pong. So what do you think Eugene V. Lyubimkin? Best regards / Mit freundlichen Grüßen, David "DonKult" Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554773: cupt: Wrong computation of preferences/pinning
David Kalnischkies wrote: > Or in short: A package version has multiply pin-settings: > - a version specific one (e.g. 5.8*) > - 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. > And this is btw what i expect with the given pin-file, > but your mileage may vary, of course. > (Or to rephrase it: how to get the same behavior in cupt?) > > I would therefore reassign the bug (again) to cupt and proceed > with improving the manpage in #557637 instead, but i don't want to > play bug-ping-pong. So what do you think Eugene V. Lyubimkin? 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. I definitely will not accept bug reports based on points like 'do what I mean, not what I say'. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer signature.asc Description: OpenPGP digital signature
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 : >> - 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554773: cupt: Wrong computation of preferences/pinning
David Kalnischkies wrote: > (i guess we simply have a different understanding of version in > this context and therefore different behavior in apt vs. cupt) Yes, seems so. > 2009/11/23 Eugene V. Lyubimkin : >>> - 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) That phrase doesn't say anything about the same version entry treating is multiple ones, one for each Packages which it belongs to. > 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. Yes, for cupt they all are the same version (which I considered natural). This concept is one of libcupt's cornerstones. Jean-Christophe, now it's up to you to decide which point you support. If the bug got reassigned to libcupt in the end, I will mark it 'wontfix'. I don't want to play reassigning ping-pong as well. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer signature.asc Description: OpenPGP digital signature
Bug#554773: cupt: Wrong computation of preferences/pinning
Eugene V. Lyubimkin a écrit : > David Kalnischkies wrote: >> (i guess we simply have a different understanding of version in >> this context and therefore different behavior in apt vs. cupt) > Yes, seems so. > >> 2009/11/23 Eugene V. Lyubimkin : - 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) > That phrase doesn't say anything about the same version entry treating is > multiple ones, one for each Packages which it belongs to. > >> 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. > Yes, for cupt they all are the same version (which I considered natural). This > concept is one of libcupt's cornerstones. > > Jean-Christophe, now it's up to you to decide which point you support. If the > bug got reassigned to libcupt in the end, I will mark it 'wontfix'. I don't > want to play reassigning ping-pong as well. My reading is now the same as yours (Eugen) : The APT preferences file /etc/apt/preferences and the fragment files in the /etc/apt/preferences.d/ folder can be used to control which versions of packages will be selected for installation. Several versions of a package may be available for installation when the sources.list(5) file contains references to more than one distribution (for example, stable and testing). APT assigns a priority to each version that is available. The crux of the problem is the definition of a "version". Either the documentation in apt_preferences man page (which belongs to apt) is fixed to say that a package version is the tuple (name,version_number,somethingelse) or a package version is indeed the tuple (name,version_number) which is the most natural for a _version_ of a _package_. For now, I think that a package version is a package and a version number. APT assigns a priority to each version that is available (quoting the man page), and one priority only. I am quite sure that if the documentation were to be fixed, certainly Eugen would (with is cupt developer hat on) would consider a package version to be whatever the documentation says it should be. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
