"complete" distributions have been made available in the early phase of that project. However, it turned out to be not useful for the following reasons.
1) This size of the resulting zip file becomes rather larger (could be close to 0.5GB by now).
2) The "complete" distribution would require a collection of lots of packages from different maintainers. If one maintainer releases a new package, either
a) "complete" new distributions are required frequently (each couple of weeks), or
b) a "complete" distribution is not issued, but each maintainer just submits his/her changes as a kind of patches.
Solution a) would require in lots of traffic and, most importantly, users will have difficulties in identifying what has been changed. In fact, the experience from old times is, that users will not update at all, since they don't want to risk a corrupt system. Moreover, only a minor fraction of released "complete" packages, would contain changes relevant to the user. Most often, the changes just concern source, that are not of general interest (=unused) anyhow.
Solution b) would result in one "complete" package, plus lots of patches from different maintainers. It would then be required to find a solution, that patches are not in conflict with each other. For the user, the number things required for download will not really change compared to individual packages, and it will be very hard to keep an overview.
3) With one "complete" package, versioning becomes difficult. If a maintainer of a small "sub"packages changes something, a new "complete" package is required. How to do the versioning? To make things clean, the versions of all packages must be synchronized to uniquely identify the "complete" package, from which the code is extracted. This would basically require to involve all maintainers of all packages when releasing a new "complete" package, or a patch.
4) The same problem becomes evident when building applications and assigning a version to them.
Solution
1) It was decided on the CS Workshop in 2006, to have individual packages for individual things.
2) Relationsships and dependencies are described in release notes and XML files. The XML files allow for programmatic veryfication of the dependencies, which is done by the CSUnpacakger. The CSUnpackager also allows to install/untinstall individual packages, and to download (missing) packages, in case of dependencies. We have clear relations between the individual packages.
3) Users that prefer to not using the CSUnpackager, have two options
a) Download and install individual packages manually. Identifying the required version is greatly simplified by the use of prepared download links (as an example see http://wiki.gsi.de/cgi-bin/view/CSframework/LV2009\).
b) Use the SCC control system SubVersion and change from one version to another by using a "switch" to the desired revision number or tag of the SubVersion reposity.
To conclude, from our (db, hb) side, there as no alternative than to small well defined packages. They can be handled, if tools like the CSUnpackager, prepared download links, or SCC are used.
Of course, the CS-framework is free software based on GPL V3. Everybody can volunteer and build "complete" packages or burn it to CD/DVD if he/she thinks, that this is useful, as long as the copyright is respected.
Regards,
dhbeck
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
"complete" distributions have been made available in the early phase of that project. However, it turned out to be not useful for the following reasons.
1) This size of the resulting zip file becomes rather larger (could be close to 0.5GB by now).
2) The "complete" distribution would require a collection of lots of packages from different maintainers. If one maintainer releases a new package, either
a) "complete" new distributions are required frequently (each couple of weeks), or
b) a "complete" distribution is not issued, but each maintainer just submits his/her changes as a kind of patches.
Solution a) would require in lots of traffic and, most importantly, users will have difficulties in identifying what has been changed. In fact, the experience from old times is, that users will not update at all, since they don't want to risk a corrupt system. Moreover, only a minor fraction of released "complete" packages, would contain changes relevant to the user. Most often, the changes just concern source, that are not of general interest (=unused) anyhow.
Solution b) would result in one "complete" package, plus lots of patches from different maintainers. It would then be required to find a solution, that patches are not in conflict with each other. For the user, the number things required for download will not really change compared to individual packages, and it will be very hard to keep an overview.
3) With one "complete" package, versioning becomes difficult. If a maintainer of a small "sub"packages changes something, a new "complete" package is required. How to do the versioning? To make things clean, the versions of all packages must be synchronized to uniquely identify the "complete" package, from which the code is extracted. This would basically require to involve all maintainers of all packages when releasing a new "complete" package, or a patch.
4) The same problem becomes evident when building applications and assigning a version to them.
Solution
1) It was decided on the CS Workshop in 2006, to have individual packages for individual things.
2) Relationsships and dependencies are described in release notes and XML files. The XML files allow for programmatic veryfication of the dependencies, which is done by the CSUnpacakger. The CSUnpackager also allows to install/untinstall individual packages, and to download (missing) packages, in case of dependencies. We have clear relations between the individual packages.
3) Users that prefer to not using the CSUnpackager, have two options
a) Download and install individual packages manually. Identifying the required version is greatly simplified by the use of prepared download links (as an example see http://wiki.gsi.de/cgi-bin/view/CSframework/LV2009\).
b) Use the SCC control system SubVersion and change from one version to another by using a "switch" to the desired revision number or tag of the SubVersion reposity.
To conclude, from our (db, hb) side, there as no alternative than to small well defined packages. They can be handled, if tools like the CSUnpackager, prepared download links, or SCC are used.
Of course, the CS-framework is free software based on GPL V3. Everybody can volunteer and build "complete" packages or burn it to CD/DVD if he/she thinks, that this is useful, as long as the copyright is respected.
Regards,
dhbeck