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

[Jean-Christophe Dubacq-2]

Eugene V. Lyubimkin a écrit :

> package cupt apt
> reassign 554773 apt
> thanks
>
> Hi Jean,
>
> Jean-Christophe Dubacq wrote:
>> Package: cupt
>> Version: 1.2.1
>> Severity: normal
>>
>> While in the process of comparing apt-get and cupt, I found this
>> discrepancy between apt-get and cupt computations of pinnings:
>>
>> LANG=C apt-cache policy xml-core
>> xml-core:
>>   Installed: 0.12
>>   Candidate: 0.13
>>   Version table:
>>      0.13 0
>>         500 http://ftp.fr.debian.org testing/main Packages
>>         100 http://ftp.fr.debian.org unstable/main Packages
>>  *** 0.12 0
>>         500 http://ftp.fr.debian.org lenny/main Packages
>>         100 /var/lib/dpkg/status
>>
>> LANG=C cupt policy xml-core
>> xml-core:
>>   Installed: 0.12
>>   Candidate: 0.12
>>   Version table:
>>  *** 0.12 501
>>         /var/lib/dpkg/status installed/ (unsigned)
>>         http://ftp.fr.debian.org/debian stable/main (signed)
>>      0.13 101
>>         http://ftp.fr.debian.org/debian testing/main (signed)
>>         http://ftp.fr.debian.org/debian unstable/main (signed)
>>
>>
>> My pinnings are as follow :
>> Package: *
>> Pin: release a=unstable
>> Pin-Priority: 100
>>
>
> I believe cupt is doing right here. From 'man apt_preferences': "If any
> specific-form records match an available package version then the first such
> record determines the priority of the package version. Failing that, if any
> general-form records match an available package version then the first such
> record determines the priority of the package version."
>
> So, you have '100' for unstable versions, and then 100 (+1) is strictly
> assigned to that version of xml-core, not looking more at any other settings,
> including 'apt::default-release'.
>
> And no, cupt has not 'stable' in its 'apt::default-release' setting by
> default, but undefined value like APT does. All option inconsistencies are
> listed in 'man cupt_vs_apt', and 'apt::default-release' is not there.
>

Should I file a bug against apt-get or the manual ? The solution for me
is obviously to to pin stable and testing to 500. However, either
apt-cache is at fault, or the manual is (I read the excerpts you quoted
the same as you). The only ambiguity resides in the definition of a
"package version" : possibly apt-get tries for each origin of a package
version and gives the higher score possible, whereas cupt matches
globally a package version (which seems to be the documented way of
proceeding).

--
Jean-Christophe Dubacq

[Eugene V. Lyubimkin]

Jean-Christophe Dubacq wrote:
> Should I file a bug against apt-get or the manual ?

I already reassigned this bug to apt, so wait for the answer from maintainers.

--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer

[David Kalnischkies-2]

>>> 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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Eugene V. Lyubimkin]

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

[David Kalnischkies-2]

(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@...>:
>> - 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 deity-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Eugene V. Lyubimkin]

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 <jackyf.devel@...>:
>>> - 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

[Jean-Christophe Dubacq]

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 <jackyf.devel@...>:
>>>> - 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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...