> Currently in CPAN you have modules like:
> Digest::MD5
> Digest::SHA
> Digest::MD5::Perl
> Digest::SHA::PurePerl
> The difference is that the first two are implemented in C and the later
> two in Perl.
This is comparible to adding a "target" to each of the modules, a
suggestion when you started this long thread. Either in the name or
with the name, we need some kind of separation when you want to leave
everything in one archive.
With the idea of "target", I think that the intention was to have them
added to distributions. But above seems to me applied to pm files.
Or is that not your intention? Currently, these problems are resolved
in the Makefile.PL: some modules try to autodetect whether to install
a binary or a pure perl implementation based on the availability of
a C compile. That isn't simple.
The main problem with this kind of solutions, is that you do not
know beforehand which tags you need to distinguish. For instance,
you may also want to release a different version for VMS (so need
an OS component), for small systems, and so forth. Multiple classes
of tags/targets/keywords?
There are at least 2 different perspectives:
. the author must be able to provide such special selection
criterium in the name to avoid name-space collissions.
. the user needs to know which selections there are: which
possible values s/he can expect and in which combinations.
An alternative solution is:
. do not standardize on name extensions: simply have the author
choose one. For instance a version number with his PauseID
added.
. have the install tools decide the best option: it should be able
to search in the meta-data of the distribution for the optimal
match with the platform it is on. The install tools need to be a
bit smarter in this respect that what we currently use.
For instance, a dependency could be:
requires: Some-Module version 2.*-DANIEL (very explicit)
requires: Some-Module version * (easy for user, best fit)
There are (in any solution) various complications:
. how do we know which versions are compatible? Other people can
release incompatible modules in the same product name.
. new releases by the same autor sometimes break the interface as
well, with a major version number increment.
. if the user does not specify an explicit version, which one to
take? Who decides the preference?
. will Perl6 version on PM files, like perl5, or on distributions
(like all other projects do)?
. how does the client get the info to do the best match? The
02packages.details file is already far too large. Server-side?
A few of these problems need to be tackled in the versioning scheme,
some are automatable, and some may require user intervention at install
time. Some new balance between them, Perl5 is very simple compared to
the need requirements.
--
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
m...@overmeer.net soluti...@overmeer.net
http://Mark.Overmeer.net http://solutions.overmeer.net
