-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Roger Ineichen wrote:
Hi Tres
Whoever released those two eggs (the '.dev-r#####' ones) need to release "real" updated packages, and then grok 0.11.1 should be released using them.
DEATH TO FAUX PACKAGES! As far as I understand, this does not happen if you depend on a KGS, right?
Does the grok release not use the KGS from Stephan?
Not yet. We intend to look at that list at some point. Of course the KGS probably doesn't contain recent enough packages to support the REST changes.
If the REST stuff depended on unreleased versions of upstream packages, then it should not have been merged until those packages were released in an acceptable (non-snapshot) form.
The other problem with KGS is that I absolutely want to fix lists of packages into Grok itself and never rely on any system that can cause the list of packages that could be updated. KGS will get bugfix releases. These will inevitably break something on occassion. I have no idea what will happen once 3.5 packages will start to appear, either.
A KGS needs to have the following properties: - The "generation zero" of any KGS is an empty set of revisions. - By default, any revision N of a KGS starts out as a "draft" version which is an empty layer over version N-1. Changes to the draft then shadow any versions in the prior revision. - Once "finalized" / "published", a given revision of a KGS can *never* be changed. - Any KGS can be derived from the published version of another KGS, with additions of new distributions / versions and updates of versions for underlying distributions. - In conjunction with a "find-links" site which promises never to remove any distribution which has been included in a published revision of a KGS, the current 'version.cfg' (and workalike) files are sufficient to establish a KGS. Without that promise, however, those files can't be considered as defining a KGS. Therefore, - Given that all distribution versions mentioned in a KGS are stored at a trusted / reliable URL, any immutable KGS revision can be trivially transformed into a PyPI package index: each distribution will have exactly one allowed version, which will point to a single URL on a reliable server. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNS+v+gerLs4ltQ4RAl/rAJ9lDeB9nOXGab+/uAithNjeMeREkwCgguHF 5qA0vftURPPCW7SR2yZVTmk= =NBMc -----END PGP SIGNATURE-----