develooper Front page | perl.perl5.porters | Postings from August 2001

SDKs Redux

Stephen Zander
August 13, 2001 09:50
SDKs Redux
Message ID:
>>>>> "Elaine" == elaine  <-HFB- Ashton <>> writes:
    Elaine> Stephen Zander and Gnat were the 2 riding herd on the SDK
    Elaine> list before it totally petered out so they may have some
    Elaine> insight to the task you are about to undertake :)

Wow! I pop my head back into my p5p mailbox for the first time in way
too long and look what I find: SDK discussions again!

Having at least skimmed the entire thread thus far I have three major

1) Bundles are a good selection process for inclusions into one or
more SDKs but do not meet the original goal of the SDK concept; that a
user be able to build a complete Perl development environment from a
single tar file, including any necessary dependencies.  SDKs are
supposed to Just Work and I don't think Bundles do.

2) SDK progress stopped because my tuit supply interfered with
finishing the initial install process, not because no agreement was
reached on a list of modules.  The work is still sitting on my laptop.

3) Module selection cannot be a democratic process.  For instance,
Graham Barr did not like the way some modules were selected and
requested that none of his modules be included.  However, the SDK
would be significantly diminished were I to abide by that request.
Such issues cannot be solved democraticly.  Building an SDK requires
consideration of two things and two things only.

One: what is best for the majority of users of Perl?  These folks may
run back-revved versions of perl, run perl on unusual platforms and
need an tested, integrated solution where there are no module
interdependency issues and a sensible complete build process exists.
That may mean I give them modules with overlapping functionality.  To
employ a bad metaphor, sometimes they'll want a star screwdriver,
sometimes a flat.  Providing One True Screwdriver doesn't work.

Two: can I legally include this module?  Can I provide not only the
perl module but any underlying libraries it may require?  This sounds
simple but is complicated by variations in licensing of both Perl
modules (no everyone uses dual-licensing) and support libraries.
Given that, if a module provides functionality not easily available
elsewhere and it can be legally included, it goes in.  Yes, I realise
that last remark may be flame-bait; I stand by it.

All that said, I agree with Elaine: any action at all is better than
the continuous conversation that has been all that's existed for over
two years.


"A duck!" Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About