----- "Miguel Enrique Cobá Martinez" <miguel.coba@gmail.com> wrote: | El dom, 09-08-2009 a las 10:29 -0700, Dale Henrichs escribió: | | > - Package to package dependencies. One can declare required | packages | > like the | > following: | > 'Example-Core-anon.9' | > 'Example-Tests-anon.3' requires: 'Example-Core' | > 'Example-AddOn-anon.1' requires: 'Example-Tests' | > 'Example-UI-anon.1' requires: { 'OB'. 'Example-AddOn'. } | > From the above statements, the package load order is derived and | used when you | > load the project: | > (ExampleProject version: '0.3') load | > It is also used to determine _which_ packages should be loaded | when an | > expression like the following is executed: | > (ExampleProject version: '0.3') load: 'Example-AddOn' | > This statement causes 'Example-Core-anon.9', | 'Example-Tests-anon.3', | > 'Example-AddOn-anon.1' to be loaded in order. | | This is very good, one thing that the package management system of | Debian has is that you can indicate a minimal version for a required | package: | | for example, following your code snippet: | | 'Example-Core-anon.9' | 'Example-Tests-anon.3' requires: 'Example-Core' minVersion: 9 | 'Example-AddOn-anon.1' requires: 'Example-Tests' minVersion: 1 | maxVersion: 3 | 'Example-UI-anon.1' requires: { 'OB' . 'Example-AddOn'. } | | This way, the package system doesn't have to install a exact version | if a group of | versions of the package required can equally work. This permits to | have a package, say | 5 of a package that have a new feature that I need in my image and not | be overwrote by | a dependency of other package that needs exactly version 3 that | doesn't have the feature | that I need. | | Maybe Metacello has this functionality, but if not, it would be, I | think, easy to add it, | just a comparation that the version available in the system meets the | criteria stated by | the package dependency. Metacello has the notion of version comparison operators (including the approximately greater than operator from Ruby Gems). These operators are used for project to project version comparison as well as comparing package versions. Currently a single operator is supported, but I intend to support range operations in a future version. | | Also, a form to force the install a package even if not all the | dependencies are met is good, | in particular to test some experimental package. This sounds like an interesting feature to consider...I'm inclined to use Notifications for these "boundary crossings" making it possible for the driver code to customize operations without burdening the core with tons of options ... but I'm just riffing:) | | For more information you can refer to the dpkg/deb/aptitude tools in | the debian system. | Of course that tools do a lot more but we don't need, at least for | now, all the features. | | | http://en.wikipedia.org/wiki/Aptitude_(program) | http://en.wikipedia.org/wiki/Deb_(file_format) | http://en.wikipedia.org/wiki/Dpkg | | All of them are GPL but I think that a new implementation, without use | the code, and in another | language, using only the ideas, is permited and can be integrated in | Pharo as MIT code. I agree that some useful ideas can be picked up from some of the other package management systems out there and I'm very open to specific suggestions. Dale