On Jan 13, Gregor Hoffleit wrote:
> Ok, maybe we better go with task-python, although I still like the idea of a
> real python package--IMHO it's a little bit more intuitive than task-python,
> and if the name is still free, why shouldn't we use it.
I do think task-python(*) makes sense. But I think a "python" package
would just encourage people to make gratuitous overarching
dependencies ("my one liner requires python, and I can't be bothered
to see what modules it uses, so I'll just depend on python"). We
ought to be more fine-grained when looking at dependencies from a
maintainer standpoint, and "python" is not much of a win over
"task-python" from the user's standpoint.
On a rambling note:
It seems to me that we ought to pursue something like "python-core" vs
"python", like Perl has done: a core "python-core" package with the
essentials (interpreter, required services as defined by the library
reference), and a "python" package that is the rest of python-base.
Of course, I don't know what the size differential would be, or even
if you could program anything worthwhile with "python-core" alone.
Somehow I doubt it... perl-core (or -base or whatever) is more driven
by "what do we need for all the perl scripts in base to work" rather
than any rational plan from an upstream standpoint. I doubt anything
I've written for Debian could work with any reasonable "python-core"
alone.
Chris
--
=============================================================================
| Chris Lawrence | Get rid of Roger Wicker this year! |
| <[EMAIL PROTECTED]> | http://www.lordsutch.com/ms-one/ |
| | |
| Grad Student, Pol. Sci. | Are you tired of politics as usual? |
| University of Mississippi | http://www.lp.org/ |
=============================================================================
