On Tuesday, 22. May 2007, Jakob Petsovits wrote:
A possible solution to that problem could be one or more description files which cause drupal.org to download a file when a project release is created, and optionally unpack it in the folder where the description file lies.
Hm, seems that this approach is still not quite usable. Let's have another try: Each project release gets an additional "External library tarball" upload field, which takes either .tar.gz or .tar.bz2 files, and on creating the release this file is unpacked into the module's root folder. After creating the release, the file can not be changed anymore. Pro: * Not more security concerns than pointing users to an external website, which is the current status * Relatively easy to incorporate into the packaging scripts: no fetches from external sources, file upload and storage managed by Drupal itself * One fixed library version for one project release. Makes it possible to use update_status also for library-only updates. * Allows modification of configuration files etc. Contra: * Makes maintainers prone to not storing patches (e.g. for configuration files) in the CVS, which increases the dependency on the maintainer * Would easily allow maintainers to subvert revision control and just upload their modules as tarballs (then again, this would be against the usage policies and lead to deactivation of the maintainer's CVS account) * Still needs to be updated by the maintainer, instead of getting the updated version from the external site. (If we want embedding of external libraries, it's impossible to overcome this problem.) That should be close to the ideal solution, assuming we want this at all. Best regards, Jakob