On Sun, 30 Jul 2000 19:47:57 +0100, Graham Barr 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
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
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
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.