On Nov 18, 2007, at 7:52 PM, Stephan Richter wrote:
On Sunday 18 November 2007, Chris McDonough wrote:
4. A new "minimal/" folder now contains an index just of the
controlled
packages. This minimal index can be used by compoze as one
contributing
index. (I have not tested this yet, can anyone try this and report
how it can
be done?)
Very cool, thank you! I'll try this.
Great. I would love to get a little write-up on how to use it, so I
can put it
on the intro page.
Compoze is not ready for prime time yet, I'm afraid. You can use it
to download all source packages from a working set and create an index
from these. But currently I think only Tres knows how to make it do
it. ;-)
Note that if the KGS really wants to be a KGS (literally "known
good",
it's a matter of semantics, not of technology):
I agree.
- An invariant must be met that only one version of each package
should be present in the index.
I disagree. This is not what this means to me. I think a KGS can
receive bug
fix releases, which the Zope 3.4 KGS does. However, no new feature
releases
are allowed.
In the Linux world, these purposes are served by separate indexes
(e.g. Debian security releases are in their own index). There's no
problem with what you're saying, it's just not a source for repeatable
installations, which is something that's required for many builds.
Even if there are bugfixes available, you may not want them, or you
may have fixed the bugs your own way already (though patches or what-
have you). Maybe the KGS isn't it, but there needs to be a way to get
the very same packages, unfailingly, every time, no exceptions for
bugfixes, etc. I wish the KGS was this but it still isn't it.
The first is true for what we have now neither of the "minimal" set
or
the set you're calling the "KGS".
Right. Note that versions-*.cfg and links-*cfg are frozen. I am
probably going
to freeze minimal/ as have minimal-*/ too.
Will they will change for bugfixes?
The second I'm pretty sure is not
true of the thing you're calling the KGS (it still mirrors the
cheeseshop regularly), I'm not sure about the intent for the
"minimal"
set.
Well, this is a limitation of the current setuptools system. In
buildout I can
only specify one index, since setuptools can have only one index. So
it is
necessary that I make all packages available in that index and this
is what I
produce as download.zope.org/zope3.4. But I have explained this
multiple
times before, so I am not going to repeat the argument any more.
Please try
buildout and see for yourself.
I have tried buildout, of course. Massaging the index to meet some
set of expectations developers have of the client they use to install
the software is fine, you did a lot of work to do this, which is
appreciated, and it's your index. But I suggest that we don't
discount the *really KGS* requirement, which is *absolutely repeatable
builds* (today, tomorrow, two years from now), and we let people know
that the KGS is not that.
In any case, thanks a lot for the work!
- C
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
