RFC: Old packages remain on the mirrors for one week

Dennis Gilmore dennis at ausil.us
Sat Aug 17 15:15:52 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 17 Aug 2013 13:14:14 +0200
drago01 <drago01 at gmail.com> wrote:

> On Fri, Aug 16, 2013 at 6:48 AM, Dennis Gilmore <dennis at ausil.us>
> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Mon, 12 Aug 2013 14:47:03 +0100
> > Richard Hughes <hughsient at gmail.com> wrote:
> >
> >> Hi all,
> >>
> >> I'd like to ask for comments on a feature I need for the Fedora
> >> Application Installer. The current yum backend in PackageKit does
> >> something like this:
> >>
> >> * yum install foo
> >> * depsolve transaction using cached metadata
> >> * download foo-0.1.noarch.rpm
> >> * error! foo-0.1.noarch.rpm doesn't exist
> >> * download latest repomd, primary
> >> * re-depsolve
> >> * download latest filelists
> >> * continue to re-depsolve
> >> * download foo-0.2.noarch.rpm
> >> * install foo using librpm
> >>
> >> Now, we do this as the metadata is cached on the client side for
> >> up to a week as we don't want to unconditionally update the
> >> metadata for every transaction, but we don't know if we can
> >> download the package without downloading all the metadata
> >> beforehand. This is incompatible with the swish UX in the
> >> application installer where we can search for things straight away
> >> without having "Downloading..." in the UI appearing at odd times.
> >> So my proposal is thus:
> >>
> >> 1. We retain old packages on the mirrors for a minimum of 7 days.
> >
> > without completely rewriting how we compose the trees this is not a
> > possibility.
> 
> Bill's mail reads a bit different ...

I suggest you re-read Bills email. the non-trivial changes are
completely redoing how we compose the trees.

Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlIPk6wACgkQkSxm47BaWfd0+ACghewKlJcOqJQHMC2N4uq4h/UJ
UyAAnApfCP3Syivq9gw19sjqP/DTsh/N
=g/Rt
-----END PGP SIGNATURE-----


More information about the devel mailing list