Debian Bug report logs - #685215
Apt pinning is broken

version graph

Package: apt; Maintainer for apt is APT Development Team <deity@lists.debian.org>; Source for apt is src:apt.

Reported by: kerncece@gmail.com

Date: Sat, 18 Aug 2012 11:21:01 UTC

Severity: important

Tags: confirmed

Found in version apt/0.9.7.4

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#685215; Package apt. (Sat, 18 Aug 2012 11:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to kerncece@gmail.com:
New Bug report received and forwarded. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 18 Aug 2012 11:21:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Kernc <kerncece@gmail.com>
To: submit@bugs.debian.org
Subject: Apt pinning is broken
Date: Sat, 18 Aug 2012 13:16:23 +0200
Package: apt
Version: 0.9.7.4
Severity: important
Tags: confirmed

I took liberty to mark this as confirmed, as it very well is and will as
such hopefully jump at the willing contributors from the top of the
outstanding bugs list. Maintainers' sympathy kindly appreciated.

I know this is kind of TL;DR, but I don't have a blog, and this is a valid
issue report with accompanying observations and proposals. Please bear
with me...


Facing it now: apt pinning, other than general pinning on release
(i.e. "Package: * \n Pin: release..."), is **broken.**

Per-package pinning doesn't work intuitively (countless forum posts around,
several bug reports below), version pinning suffers serious bugs (doesn't
work, doesn't glob() properly [4])...

This important bug spans 9 years (since 2003), several directly-related bug
reports:

 [1] http://bugs.debian.org/254820 ,
 [2] http://bugs.debian.org/387218 ,
 [3] http://bugs.debian.org/443565 ,
 [4] http://bugs.debian.org/454080 ,
 [5] http://bugs.debian.org/554773 ,
 [6] http://bugs.debian.org/620249 ,

several directly-related bug reports that were nonchalantly demoted to
wishlist-items (?!) by Matt Zimmerman:

 [7] http://bugs.debian.org/216688 ,
 [8] http://bugs.debian.org/239247 ,
 [9] http://bugs.debian.org/242738 ,
[10] http://bugs.debian.org/276602 ,
[11] http://bugs.debian.org/483147 ,
[12] http://bugs.debian.org/312589 ,

and many "apt-cache policy", general pinning and its documentation related
bugs:

[13] http://bugs.debian.org/166032 ,
[14] http://bugs.debian.org/308445 ,
[15] http://bugs.debian.org/301464 ,
[16] http://bugs.debian.org/405262 ,
[17] http://bugs.debian.org/557637 ,
[18] http://bugs.debian.org/602094 ,
[19] http://bugs.debian.org/623706 ,
[20] http://bugs.debian.org/673760 . (...)



All these (and possibly other, merged) bug reports, and countless forum
posts [21] desperately say one thing:

  ** Fix `apt-pkg/policy.cc` and rewrite documentation pertaining it! **

Let's do it once and for all?


I don't know who first 'invented' pinning as implemented now, but she
most certainly did it wrong, mainly by making it counter-intuitive.
The argument that "just RTFM, the specification is such and is correct," in
spite of being unable to satisfy a most common use case —that is, simple
package pinning— is a non-argument!


The problem lies in assigning priorities. The per-package/version priorities
aren't even priorities in the general sense, but rather some kind of minimum
priority required, as detailed in Carlo Wood's comprehensive pinning
documentation & errata [22], the author of which reported [2]. This
limitation is a serious usability issue.

Furthermore, one cannot even use an external EDSP/CUDF dependency solver and
expect coherent results, with APT::Solver::Strict-Pinning set to "false" or
otherwise, since package (or version) pins aren't even properly propagated
into EDSP/CUDF dumps, that because policy.cc simply doesn't account for
those pins correctly.

I kindly ask you to spare the discouragement warnings in this instance:
apparently there are valid use cases for pinning ([1-12, 21])!


The problematic policy.cc code may be extremely hard to fix if one is not
well versed in C++ (which I'm not), especially with so few convenience
dependencies, but fuck me if somebody is not up to the challenge.

Whoever fixes this does not only get to enjoy a crate of virtual beer (and
eternal satisfaction by the houri, acknowledged contribution one can put
in her résumé, etc. other immaterial pleasures), but I vow to
Flattr/PayPal/Kickstarter $50 myself, and I am only a poor student.

Since this is not a release-critical bug, there's enough time for testing
until the next freeze.


[21] http://www.google.com/search?q=apt+pinning+doesn't+work
[22] http://carlo17.home.xs4all.nl/howto/debian.html#errata



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#685215; Package apt. (Sat, 18 Aug 2012 12:03:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to kerncece@gmail.com:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 18 Aug 2012 12:03:05 GMT) Full text and rfc822 format available.

Message #10 received at 685215@bugs.debian.org (full text, mbox):

From: Kernc <kerncece@gmail.com>
To: 685215@bugs.debian.org
Subject: Re: Apt pinning is broken
Date: Sat, 18 Aug 2012 13:59:02 +0200
Since I opened this new bug, I'd like to add my specific use case as well:

Naturally, I want my system stable. Perhaps some time into the release
cycle, I want my user apps updated for the sake of new features, so I pull
them from testing. Chromium and Iceweasel, perhaps with more stable
(supposedly) upstream development, I want on the bleeding edge.
Perhaps I want to stay on Gnome 2 before I move to Xfce for good.
Thus, I end with the following apt preferences:

-- /etc/apt/preferences --

Explanation: I want the base of my system stable.
Package: *
Pin: release a=stable
Pin-Priority: 503

Package: *
Pin: release a=testing
Pin-Priority: 502

Package: *
Pin: release a=unstable
Pin-Priority: 501

Explanation: In some apps, I prefer features over stability.
Package: gimp libreoffice pidgin vlc
Pin: release a=testing
Pin-Priority: 505

Explanation: Other apps may be stable by design. Or I don't really care. D:
Package: chromium iceweasel
Pin: release a=unstable
Pin-Priority: 505

Explanation: But under no condition ever install default gnome (3) package.
Package: gnome
Pin: version 3*
Pin-Priority: -1

-- end /etc/apt/preferences --

But hey!, you say, that gimp and pidgin pull a hell of a long dependency
chain from testing as well...

True. But my kernel, my init scripts, daemons, desktop, ... likely all
remain stable.

With above preferences, with all that software initially installed, running
apt-get upgrade, I should end with gimp, libreoffice, pidgin, and vlc from
testing, unstable chromium and iceweasel, and gnome3 (likely with some of
its apps) nowhere to be seen.

Except that that doesn't work because all those package pins have dependencies
in their respective releases and those dependencies aren't pinned highly
enough as well, so, unless packages were initially installed with -t switch,
apt determines upgrade request to be unsolvable.

(BTW, I'd like to report that the external dependency solver called 'apt'
seems to pay no regard to the APT::Solver::Strict-Pinning setting.)

But that's what external dependency solvers are for! Using the above apt
configuration line, I can tell my sophisticated solver (really just a greedy
one) to get dependencies top-down: What it can satisfy from stable, from
stable; what it can't satisfy from stable but can from testing, from testing,
and the remaining from unstable, all according to the specified release pins.

Behold, awe the Debian mixed system, the truly Universal OS that is itself a
multi-level rolling release.



Argument
--------
What you're saying above can be easily achieved with pinning as implemented
now, and a careful use of apt-get command line, namely `-t` switch or
`pkgname/release` parameter.

Counter-argument
----------------
Say package A (from testing) depends on packages B, C, D, E, F, G. The
versions of these dependencies are such that versions of B, C, D, and E
could be satisfied from stable, but F and G need to be from testing as well.
All release pins as in above preferences.
Either:
$ sudo apt-get install A/testing
fails, because F and G are pinned to stable, but those two can't satisfy the
requirement of A. Or:
$ sudo apt-get -t testing install A
works, but it pulls all those packages from testing, possibly and
unnecessarily (!) making the system less stable.
Ergo, to satisfy above "prefer stable, but adapt if needed" requirement, an
external solver (with Strict-Pinning=false) is required to operate on a
working pinning implementation.
(The alternative is to install each dependency separately, which then really
turns the process into a PITA.)



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#685215; Package apt. (Sat, 18 Aug 2012 12:12:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to kerncece@gmail.com:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 18 Aug 2012 12:12:05 GMT) Full text and rfc822 format available.

Message #15 received at 685215@bugs.debian.org (full text, mbox):

From: Kernc <kerncece@gmail.com>
To: 685215@bugs.debian.org
Subject: Re: Apt pinning is broken
Date: Sat, 18 Aug 2012 14:07:09 +0200
Namely, what I, as a user, would like only is that pinning per package
(wildcarded) name or version works, and that those more specific pins are
propagated to EDSP/CUDF dumps, i.e. in the EDSP dump, the APT-Pin field for
"package=chromium,version=whatever-is-available-in-unstable" stanza says
505 (as per above /etc/apt/preferences) instead of 501 as it does now.

If I got it wrong, and the current implementation is indeed correct, I'd
very much care for having the broad ideas behind it explained to me.
(Though I doubt it as maintainers have before admitted to behavior being
kind of fuzzy.)



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#685215; Package apt. (Sat, 18 Aug 2012 12:21:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to kerncece@gmail.com:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 18 Aug 2012 12:21:09 GMT) Full text and rfc822 format available.

Message #20 received at 685215@bugs.debian.org (full text, mbox):

From: Kernc <kerncece@gmail.com>
To: 685215@bugs.debian.org
Subject: Re: Apt pinning is broken
Date: Sat, 18 Aug 2012 14:16:27 +0200
I'd like to propose a new policy view.
This is the current output of "apt-cache policy" (modified from [22]):

-- apt-cache policy <package-name> --

<package-name>:
  Installed: <installed-version>
  Candidate: <version-installed-when-doing-apt-get-upgrade>
  Package-Pin: <version-of-Pin-in-etc-apt-preferences>
  Version table:
 *** <version-available-in-repos-1&2> <more-specific-priority>
       <priority-of-source-1>  <repository-1>
       <priority-of-source-2>  <repository-2>
     <other-version-available-in-repos-3&4> <more-specific-priority>
       <priority-of-source-3>  <repository-3>
       <priority-of-source-4>  <repository-4>

-- end apt-cache policy package-name --

The breakdown of the three dubious fields is this:

<version-of-Pin-in-etc-apt-preferences>
  This field marks the version that corresponds to the first-matched more
  specific rule (e.g. with "Package: <package-name>" and/or "Pin: version
  3*"). This version has the priority <more-specific-priority>.
  IMHO, this field is completely redundant.

<more-specific-priority>
  This field is the Pin-Priority that corresponds with the first-matched
  more specific form ("Package: <package-name>" and/or "Pin: version 3*").
  This field too, IMHO, is a design flaw, is redundant and should be removed.

<priority-of-source-X>
  This field corresponds to the Pin-Priority of the whole
  release/archive/origin set with wildcard "Package: *" (called a general
  form in the manual).

I kindly challenge your views on two IMHOs above.

I propose a a new "apt-cache policy" output:

-- new apt-cache policy <package-name> --

<package-name>:
  Installed: <installed-version>
  Candidate: <version-installed-when-doing-apt-get-upgrade>
  [Package-Pin: general|specific]
  Version table:
 *** <version-available-in-repos-1&2>
       <priority-of-source-1>  <repository-1>
       <priority-of-source-2>  <repository-2>
     <other-version-available-in-repos-3&4>
       <priority-of-source-3>  <repository-3>
       <priority-of-source-4>  <repository-4>

-- end new apt-cache policy <package-name> --

Package-Pin property is marked optional, and it only tells whether the
package is being pinned at all and whether the pin is only a general form
(release-wide) pin, or a more specific pin for that package/version is in
effect.

The breakdown of the dubious field here is:

<priority-of-source-X>
  The cumulative all-things-considered priority of package <package-name>
  (set with specific form pin stanza), version
  <version-available-in-repos-Y> (set with specific form pin stanza) from
  <repository-Z> (set with general form pin stanza or APT::Default-Release).

Thus, a single priority is set for each triplet <package, version, source>
(which is supposed to be but absolutely not the case currently, and
is instead more like what cupt does). Among the highest
<priority-of-source-X> the one with the highest
<version-available-in-repos-Y> wins and becomes the Candidate.

As presented in the follow-up algorithm pseudo code, this is easily achieved
if the policy regarding rules being first-match is reversed and
instead the last general rule wins and is overwritten by the last relevant
specific rule (if such exists).

Everything else regarding priorities and policy remains as currently
documented.


Backward-compatibility notice & Disclaimer
------------------------------------------
AFAIK, current implementation didn't allow for complicated apt_preferences
setups that could have break under this "new" policy.
I don't know how else these priorities are used internally throughout the apt
suite, and who else relies on "apt-cache policy" output being exactly as is.



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#685215; Package apt. (Sat, 18 Aug 2012 12:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to kerncece@gmail.com:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 18 Aug 2012 12:33:03 GMT) Full text and rfc822 format available.

Message #25 received at 685215@bugs.debian.org (full text, mbox):

From: Kernc <kerncece@gmail.com>
To: 685215@bugs.debian.org
Subject: Re: Apt pinning is broken
Date: Sat, 18 Aug 2012 14:31:25 +0200
I'd like to propose an algorithm that, if I'm not mistaken, results in above
policy.

Presuppositions
---------------
A general form rule or stanza is one that has "Package: *" AND "Pin:
<anything-except version>".

A specific form rule or stanza is one that has "Package: <package-list>" OR
"Pin: version" where <package-list> is a space-separated list of glob() or
regular expressions.

Above is in accordance with current documentation.

Algorithm
---------
Input = list of actionable packages, e.g. the space-separated list of
packages passed to apt-get install/remove/... along with all dependencies

Preferences = parse all Dir::Etc::preferences and Dir::Etc::preferencesparts,
sorting all general forms before all specific forms. Preferences must also
contain rules for APT::Default-Release or matching command-line switch.

for package in Input:
  for rule in Preferences.general_form_rules:
    if contains(rule.source, package):
      set_priority(<package,
                    package_version_in(package, rule.source),
                    rule.source>, rule.priority)

  # more specific rules may overwrite general ones
  for rule in Preferences.specific_form_rules:
    if (rule.is_version_pin &&
        versions_match(package, rule.version)):
      if matches(package, rule.name):
        for source in get_sources_for(package,
                                      versions_match(package,
                                                     rule.version)):
          set_priority(<package,
                        versions_match(package, rule.version),
                        source>, rule.priority)
    else:  # not rule.is_version_pin
      if matches(package, rule.name):
        set_priority(<package,
                      package_version_in(package, rule.source),
                      rule.source>, rule.priority)

  package.candidate = max_version(max_priority(package))


  # the rest is as currently implemented...
  if (package.candidate.version < package.installed_version &&
      package.candidate.priority < 1000):
    error 'need priority over 1000 to downgrade'
  ...


I'd like to comment briefly on some of the above functions:
package_version_in(pkg, src) --- returns the version of pkg in src
versions_match(pkg, ver) --- returns pkg versions that matches ver glob if any
get_sources_for(pkg, ver) --- returns sources that contain pkg with version
in ver
matches(pkg, name) --- name can be a list of glob-like expressions

This is my take on what the algorithm roughly could look like. I agree it
looks kind of scripty, and I don't know exactly how easily this translates to
C++. Further, I'm not sure the algorithm works with all apt actions besides
simple install or upgrade. But I promise to implement an external solver
working as proposed in comment #2 if someone fixes the policy so that
EDSP/CUDF dump contains appropriate package pins.

I believe that with above-like algorithm, and some further documentation
effort, the bugs listed in OP can be finally marked as fixed, apt leading
Debian, as it always has, to an even brighter future.

But I fully admit to having little knowledge about apt inner working, Debian
packaging, Debian packaging policy, Debian release cycle, etc., I just want
to help the issue get resolved. :-)

Please contribute your views, questions, concerns, ideas...
And my $50 offer remains wide open. Please feel free to chip in.



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#685215; Package apt. (Tue, 18 Mar 2014 12:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Malthe Borch <mborch@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Tue, 18 Mar 2014 12:33:05 GMT) Full text and rfc822 format available.

Message #30 received at 685215@bugs.debian.org (full text, mbox):

From: Malthe Borch <mborch@gmail.com>
To: 685215@bugs.debian.org
Subject: Re: Apt pinning is broken
Date: Tue, 18 Mar 2014 13:30:48 +0100
[Message part 1 (text/plain, inline)]
How difficult would it be to implement a pinning policy that only
allowed packages released up until some timestamp:

-- /etc/apt/preferences --


Explanation: I want a system current as of some date.
Package: *
Pin: release a=stable <= 2014-03-18T12:00:00Z

This would be very useful in situations where you test out a staging
system and want to upgrade a production system. In this case, you'd
like to ensure that you only get the upgrades you have tested out in
the staging environment.
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#685215; Package apt. (Tue, 18 Mar 2014 12:39:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julian Andres Klode <jak@jak-linux.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Tue, 18 Mar 2014 12:39:05 GMT) Full text and rfc822 format available.

Message #35 received at 685215@bugs.debian.org (full text, mbox):

From: Julian Andres Klode <jak@jak-linux.org>
To: Malthe Borch <mborch@gmail.com>, 685215@bugs.debian.org
Subject: Re: Bug#685215: Apt pinning is broken
Date: Tue, 18 Mar 2014 13:34:15 +0100
On Tue, Mar 18, 2014 at 1:30 PM, Malthe Borch <mborch@gmail.com> wrote:
> How difficult would it be to implement a pinning policy that only allowed
> packages released up until some timestamp:
>
> -- /etc/apt/preferences --
>
> Explanation: I want a system current as of some date.
> Package: *
> Pin: release a=stable <= 2014-03-18T12:00:00Z
>
> This would be very useful in situations where you test out a staging system
> and want to upgrade a production system. In this case, you'd like to ensure
> that you only get the upgrades you have tested out in the staging
> environment.

Impossible. We do not know when the packages were released.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#685215; Package apt. (Tue, 18 Mar 2014 12:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Malthe Borch <mborch@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Tue, 18 Mar 2014 12:51:05 GMT) Full text and rfc822 format available.

Message #40 received at 685215@bugs.debian.org (full text, mbox):

From: Malthe Borch <mborch@gmail.com>
To: Julian Andres Klode <jak@jak-linux.org>
Cc: 685215@bugs.debian.org
Subject: Re: Bug#685215: Apt pinning is broken
Date: Tue, 18 Mar 2014 13:48:27 +0100
[Message part 1 (text/plain, inline)]
The local computer time is encoded in the GPG signature:

If you verify using ``gpg --verify``.

    gpg: Signature made Fri 14 Feb 2014 09:30:32 PM CET using RSA key ID
B35FEC3C

This was taken from the latest release of apt-cacher-ng [1].

It's contingent on the release system's local time being accurate, but I
bet it's at least accurate to the nearest day, and most likely to the
minute or even second.

[1]
http://ftp.debian.org/debian/pool/main/a/apt-cacher-ng/apt-cacher-ng_0.7.25-1~bpo70+1.dsc


On 18 March 2014 13:34, Julian Andres Klode <jak@jak-linux.org> wrote:

> On Tue, Mar 18, 2014 at 1:30 PM, Malthe Borch <mborch@gmail.com> wrote:
> > How difficult would it be to implement a pinning policy that only allowed
> > packages released up until some timestamp:
> >
> > -- /etc/apt/preferences --
> >
> > Explanation: I want a system current as of some date.
> > Package: *
> > Pin: release a=stable <= 2014-03-18T12:00:00Z
> >
> > This would be very useful in situations where you test out a staging
> system
> > and want to upgrade a production system. In this case, you'd like to
> ensure
> > that you only get the upgrades you have tested out in the staging
> > environment.
>
> Impossible. We do not know when the packages were released.
>
> --
> Julian Andres Klode  - Debian Developer, Ubuntu Member
>
> See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
>



-- 
---
Malthe Borch
mborch@gmail.com
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#685215; Package apt. (Tue, 18 Mar 2014 16:33:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julian Andres Klode <jak@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Tue, 18 Mar 2014 16:33:10 GMT) Full text and rfc822 format available.

Message #45 received at 685215@bugs.debian.org (full text, mbox):

From: Julian Andres Klode <jak@debian.org>
To: Malthe Borch <mborch@gmail.com>
Cc: 685215@bugs.debian.org
Subject: Re: Bug#685215: Apt pinning is broken
Date: Tue, 18 Mar 2014 17:29:29 +0100
On Tue, Mar 18, 2014 at 01:48:27PM +0100, Malthe Borch wrote:
> The local computer time is encoded in the GPG signature:
> 
> If you verify using ``gpg --verify``.
> 
>     gpg: Signature made Fri 14 Feb 2014 09:30:32 PM CET using RSA key ID
> B35FEC3C
> 
> This was taken from the latest release of apt-cacher-ng [1].
> 
> It's contingent on the release system's local time being accurate, but I
> bet it's at least accurate to the nearest day, and most likely to the
> minute or even second.
> 
> [1]
> http://ftp.debian.org/debian/pool/main/a/apt-cacher-ng/apt-cacher-ng_0.7.25-1~bpo70+1.dsc

We do not have the .dsc files locally, and we do not store the dates in the
indices we download.

Please do not top-post.
-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Please do not top-post if possible.



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#685215; Package apt. (Wed, 19 Mar 2014 09:33:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Malthe Borch <mborch@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Wed, 19 Mar 2014 09:33:09 GMT) Full text and rfc822 format available.

Message #50 received at 685215@bugs.debian.org (full text, mbox):

From: Malthe Borch <mborch@gmail.com>
To: Julian Andres Klode <jak@debian.org>, Malthe Borch <mborch@gmail.com>, 685215@bugs.debian.org
Subject: Re: Bug#685215: Apt pinning is broken
Date: Wed, 19 Mar 2014 10:28:25 +0100
[Message part 1 (text/plain, inline)]
On 18 March 2014 17:29, Julian Andres Klode <jak@debian.org> wrote:

> On Tue, Mar 18, 2014 at 01:48:27PM +0100, Malthe Borch wrote:
> > The local computer time is encoded in the GPG signature:
> >
> > If you verify using ``gpg --verify``.
> >
> >     gpg: Signature made Fri 14 Feb 2014 09:30:32 PM CET using RSA key ID
> > B35FEC3C
> >
> > This was taken from the latest release of apt-cacher-ng [1].
> >
> > It's contingent on the release system's local time being accurate, but I
> > bet it's at least accurate to the nearest day, and most likely to the
> > minute or even second.
> >
> > [1]
> >
> http://ftp.debian.org/debian/pool/main/a/apt-cacher-ng/apt-cacher-ng_0.7.25-1~bpo70+1.dsc
>
> We do not have the .dsc files locally, and we do not store the dates in the
> indices we download.


I see – but the system that generates these indices might first download
and verify the .dsc files, extract the signature date and provide that as
an additional metadata field in each package index section.
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#685215; Package apt. (Thu, 20 Mar 2014 13:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to david@kalnischkies.de:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Thu, 20 Mar 2014 13:15:05 GMT) Full text and rfc822 format available.

Message #55 received at 685215@bugs.debian.org (full text, mbox):

From: david@kalnischkies.de
To: Malthe Borch <mborch@gmail.com>, 685215@bugs.debian.org
Subject: Re: Bug#685215: Apt pinning is broken
Date: Thu, 20 Mar 2014 14:11:38 +0100
[Message part 1 (text/plain, inline)]
On Wed, Mar 19, 2014 at 10:28:25AM +0100, Malthe Borch wrote:
> On 18 March 2014 17:29, Julian Andres Klode <jak@debian.org> wrote:
> 
> > On Tue, Mar 18, 2014 at 01:48:27PM +0100, Malthe Borch wrote:
> > > The local computer time is encoded in the GPG signature:
> > >
> > > If you verify using ``gpg --verify``.
> > >
> > >     gpg: Signature made Fri 14 Feb 2014 09:30:32 PM CET using RSA key ID
> > > B35FEC3C
> > >
> > > This was taken from the latest release of apt-cacher-ng [1].
> > >
> > > It's contingent on the release system's local time being accurate, but I
> > > bet it's at least accurate to the nearest day, and most likely to the
> > > minute or even second.
> > >
> > > [1]
> > >
> > http://ftp.debian.org/debian/pool/main/a/apt-cacher-ng/apt-cacher-ng_0.7.25-1~bpo70+1.dsc
> >
> > We do not have the .dsc files locally, and we do not store the dates in the
> > indices we download.
> 
> 
> I see – but the system that generates these indices might first download
> and verify the .dsc files, extract the signature date and provide that as
> an additional metadata field in each package index section.

Or you do what everyone else with this usecase does: local mirror
(and for prototyping snapshot.debian.org is probably handy) as you
otherwise will soon hit a problem:

The date in the dsc file is the date of the build/signature of this
version, not the date this version entered the release. jessie will
release with software build in 2014 as well as software last build in
2010. No problem so far, right? Well, if you use jessie now and you pin
it like you proposed to a release of a weeks ago your chosen release
will not remain stable. Everytime a package is unblocked and transitions
from unstable to testing you might have a new package in your release as
the date can be in the past, even if it has just entered in your view.

Or in other words: Pinning is a way of mix and matching different releases,
not a way to manage the releases itself.


Best regards

David Kalnischkies
[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 06:15:17 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.