* Daniel Carrera (daniel.carr...@theingots.org) [090530 20:54]: > 3) A high-level install tool, analogous to yum or apt, that uses the > CPAN network and resolves dependencies. > Mark O. is most interested in (3).
These are all things which I do *not* play in the layers I want to build. Although I do have an opinion on these subjects (if you know me: I have opinions on everything) but they are all not included in my design. Wrong abstraction layer. A pity you didn't want to read the paper. My Archiver implementation defines ways how to specify the meta-data for dependencies, because that is a common need, but does not resolve dependencies. It provide sufficient means of search so you can investigate the dependency details before you start downloading releases, but in general, there are nasty application dependent interpretations in these details. Interpreting dependency information sometimes requires human intervension. For instance: do you want to upgrade to a higher version which breaks api (and triggers the upgrade of a dozen other modules on your system) or stay in the maintenance track of the older api. (example is Mail:: SpamAssassin 2 vs 3) These problems cannot be resolved server-side. Apt or yum are just like CPAN install tools. Nothing more. So outside my personal scope. (But important to Perl6) Please clarify in your spec what you mean with "package" in a dependency. Is it about a single distributed version (what I call a "release" into the archive), or a release with a certain product name, or with a certain tag. Or any of those: how would you specify that? And how would you denote ranges of conflicting packages? Well, maybe start with putting that in your wishlist. And conflicting/dependencies in licenses? How would you resolve dependency conflicts? Design human intervention in this process of dependency processing. How do you handle external dependencies to Linux distribution components like database software, which change name with each new release of each linux distribution? Will we lockin Perl to a few well known distributions, or do week keep our trandition open mind. So: please pick from http://lwn.net/Distributions/ (currently 548 distros listed) which you want to support... and wait for other people to add more. Perl is one of the last pure English open source projects. When you install a localized KDE or Gnome *everything* (>95%) gets translated. But not Perl! You must include description and keywords in various languages. Can other people contribute translations? How will they add those to CPAN? The Meta.YML specs are already further than what you propose. Go to a Perl QA Hackathon and see how hard people work to get Meta.YML extended! (last year Oslo, last March in Birmingham) Reuse that. > I propose that we work on (1) and (2) first and do (3) later. (3) is > quite independent of (1) and (2). Mark might want to check that the > package format includes enough meta-data to not conflict with is ideas. There is no way that it can conflict, as long as it is well defined. Have a look at the Kwalify module, or use the horribly (but more widely known) XML Schema's to make it well-defined. My very extended meta-data design probably gives you enough to shop for your wishlist. But I may lack a few things and can add those easily on this stage of the project. Or you can put those in the application specific meta-data block which Pause6/CPAN6 supports. (Which is a pity: unification of meta- data has many advantanges) As examples of how you could adapt your design to my plans: . you do not need to organize file signatures, because those are (far more flexible) already provided on the transport layer of CPAN6. (where it fits logically) . you do not need any packing or unpacking of trees, because that is also part of my transport layer: sender and receiver decide whether they pack temporarily or not. . I offer nice standard solutions for identity management (authors) and licenses. But these are probably automatically translatable. I will keep an eye on your growing list of meta-data needs, and see whether there appear things which are not covered in my specs yet. We need more and better meta-data, not a reinvented wheel. -- MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
