>>>>> On Sun, 30 Jul 2000 19:47:57 +0100, Graham Barr <[EMAIL PROTECTED]> said: >> > One thing that came up during the meeting was that there should be >> > one OSD per dist which covers all implementatons. I was skeptical >> > of this at the time, but now having thought a bit more I think it >> > would work. >> >> I'd really like to keep the way CPAN is working now, just start using >> well specified metadata for it. The OSD probably promises too much. In >> practice it (well, its cousin in law PPD) only has proofed working for >> one architecture -- or are there any other known places it ever was >> used? > OSD can contain all the meta data we need. Merging is not strictly > needed, we can use OSD without it. But to a large extent it does make > sense. This is because the only parts different between two OSDs for > the same distribution are the IMPLEMENTATION parts which describe which > platform a givein distribution is for. So only the IMPLEMENTATION and the RESULT (or MANIFEST) or so could be described in secondary (aka binary) distributions, accompanied by a pointer to the primary distribution. >> And probably PPD only works for that one architecture because we have >> CPAN. > At the moment I see it as completly separate. The PPD files point to > somewhere else where the binary dists exist. Using OSd can bring CPAN > and PPD back together. Sure, this is an important goal that I'd like to achieve. But at the same time we should try to avoid the flaws in PPD. E.g. The idea to have author's credentials in the distribution data is against good old database rules to normalize data before storing them. >> Seeing it from that perspective, the only merging needed would be an >> extraction into the modules/02packages.details.txt.gz file. For a >> first implementation this should be enough. > I don't see the point in defining our own file format when there is an > extensible one out there that can be used. I have no doubt in XML as file format, this is certainly OK, and it is extensible. And the file format of 02packages' file will need to be supported for a while for backwards compatibility. Merejn has volunteered to suggest us something better for the aggregate files. Let's hear what he comes up with. > The first place we need to > get the meta data is into the distribution, which OSD can help with. Exactly, no argument here. > Why then change the format to disribut it on CPAN, that surely does not > make any sense. I'm not arguing for changing the format but to optimize it for what we are doing. The most urgent points I would like to see addressed are: - List of and checksums for all files in the distribution, - a signature - a list of namespaces used within the files that are being installed by this distribution - a list of version numbers >> XML databases seem to tend to become very large collections of data, >> like database dumps. We should not do too much preprocessing of them >> as any transformation can be regarded as redundant bloat. > It is one file for each source distribution uploaded. That can hardly > be called large. Sorry, I wasn't clear enough. I was talking about the collection of all (future) OSDs on CPAN and elsewhere. >> >> and how do we get people not only to use it but use it consistently. >> >> It's food for thought anyway. >> >> > Well the generation of it would be part of makemaker. The really important >> > stuff would be added done by makemaker. The author would then be able >> > to add other info (like description, webpage etc) that would be of >> > use to indexers. >> >> I'd think, that the safer approach would be to add keywords to >> makemaker as needed and let makemaker write the OSD. That would help >> to catch errors early. Hand-written XML seems risky to me. > I think a template appraoch is more extensible. MakeMaker cannot know > about everything that goes into the OSD file. OSD defines a way for people > to add thier own tags. This would not be very easy from MakeMaker. IMO the > user should have a template OSD which they fillout and then MakeMake reads > this, adds whats needed and then writes a new OSD which the information > it does know (version etc.) which is inluded in the distribution. Let me withdraw what I said. I think, it's OK as you suggest. But we should offer the user the option to not filling in anything into any file except into the Makefile.PL and leaving all the work to MakeMaker. That way we would have a very smooth transition path, higher acceptance, less intrusion into the developers' working place. Ideally, we would change what 'make dist' is doing now without asking the user to do anything. -- andreas
