cg at cdegroot.com (Cees de Groot) wrote:
>  <goran.hultgren at bluefish.se> said:
> >I agree this would be very nice - Michael has also mailed me about this.
> >The SSTCPW is probably to just add another url called "Download tests
> >url" or something. Optional of course.
> >
> It's probably better to tackle it in SAR
> (<whatever-the-reserved-directory-name-is>/tests is run if available, if it
> throws an exception, the user is prompted to mail a bug report). I agree with
> others that you shouldn't make this an optional thing.

You just said "if available" which sounds optional to me! :-)
My point was that if we can not install a package without its tests
then...
Well, it feels a bit weird to me. If I want to produce a minimal image
those tests are - no matter how nice and secure they make me feel -
simply baggage during deployment/runtime.

But sure, if people use SAR and there is an optional convention for
including tests in there then fine by me. Perhaps somehow the user can
discard the tests later or choose not to install them when installing
the sar or whatever?

> And I support giving a long hard look at CPAN. Sometimes I don't like
> myself for not liking Perl more because of that excellent institution
> (do you follow this? ;-)). The analogy here is that the CPA Network has
> the cataloguing and distribution bit, while the tarballs are setup to a
> special convention that includes makefiles, pre-condition checks (apart
> from the CPAN dependencies that aid in downloading and installation order,
> IIRC the distribution packages themselves check whether all dependencies are
> satisfied), and tests. 

Actually, even though most packagesystems do include the dependencies
inside the package we (especially Daniel and I) are opting for
externalizing this as a "package configuration" which there may be
several for a given package release. An example of a package
configuration in readable english:

"Spaghetti tracer 1.0 has been verified by Daniel Vainsencher to work
with prerequisites DVS
1.34 and Connectors 1.3 on top of base image 3.2."

So a package configuration contains:
1. Which package release it refers to. "Spaghetti tracer 1.0"
2. What package releases it was tested with as prereqs, "DVS 1.34" and
"Connectors 1.3".
3. Who it is that verified this configuration. "Daniel Vainsencher".
4. Which base image this was tested in. "3.2" (this last part is
interesting. I haven't decided but it seems to me that base images could
be considered as some kind of package. They have releases, they can be
downloaded, you can depend on them etc. This would in that case unify
this last step with step 2)

Compared to Debian:

1. A package configuration is a tested "setup" of a specific version of
a package X. It does not apply in general for package X.
2. There may be several tested "configurations" for one package. Not
only the maintainer can publish these.
3. There is no boolean algebra or dependencies on packages in general -
only on specific releases.
4. When a new configuration is discovered or when a dependency needs to
be added we don't need to release a new version of the package itself.

Possibly we could complement a package configuration with conflicts as
in Debian, but I haven't thought it through.

Anyway, my main point here is that I actually think a package should be
minimal in this respect and having the package configuration as a
separate entity gives us more flexibility but at the same time it is
quite simple to understand.

I tested these ideas and more on several people at OOPSLA and all seemed
to like it.

regards, Göran