eclipse-pydev: New upstream release 1.3.13 avaible

[Derek Broughton]

Kristian Rink wrote:

> Derek Broughton schrieb:
> 
>> My point being that there's nothing "platform dependent" about apt -
>> eclipse could have packaged all their bits as .debs, and installed them
>> with java just as easily as using their own system (probably _more_
>> easily).
> 
> Maybe. But maybe having a different system and approach of managing
> packages considered "internal" to an application platform compared to
> having a general purpose operating system distribution is not a good
> thing. The question is: Would that, consequently, work on, say, Solaris
> or win32? Wouldn't, even having all the Eclipse modules packaged as
> .debs, the "initial" eclipse.deb depend upon rather platform-specific
> things (be that a given version of JDK)? How to deal with that on win32
> where the idea of having a "general" apt package tree having most if not
> all applications installed this way is next to illusionary?

Exactly! :-)  The problem is not that Eclipse or anybody couldn't do it this
way, it's that unless you get buy-in from everybody (or at least enough
different groups to force a de facto standard) it doesn't work.

> Or maybe, instead of that, we should ponder whether the idea of an
> "one-size-fits-all" package management is in itself flawed? No matter
> where I look, there are smart ideas fitting right the very purpose. Take
> Ruby Gems, take perls CPAN, take maven2 or apache ant/ivy or the Eclipse
> Update Site mechanism - isn't that what Unix should be about, as well: a
> set of simple tools tailored to meet right one given purpose? 

Well, no.  Unix has always worked on the concept of reuse - not reinventing
existing tools.  Maven, easy_install, rpm & apt, at least, all do
dependency checking and installation of versions.  There's no credible
reason why there should be four of them, except that every developer felt
that there was something wrong with the others.

> Most of 
> these have been built by communities working cross-platform in order to
> distribute their tools, most of them are far from perfect, but most of
> them do serve their purpose rather well.

I disagree, at least in the case of Maven and CPan, which do _their_ jobs
just fine but tread all over apt and vice-versa.
 
> From that point of view, I honestly wonder what's the point in, say,
> wrapping up a hundred dozens of perl modules taken off CPAN for the sake
> of having them installable via apt rather than providing a lean, easy
> way of allowing users to quickly install perl modules like they would on
> every other operating system not necessarily .deb based - using CPAN
> directly? Drastically speaking, this in my opinion is where apt and
> friends absolutely fail

And again I disagree.  When I install something via cpan, _I_ need to know
which version I need.  If I install it via apt, apt updates it if some
other package needs a newer version.  Consequently, I never use cpan. 
Maven seems to mostly do this - but dependency checking is either weak, or
the project I'm working with got it wrong :-)  

> Given a portable package (depending upon python and some additional
> stuff), not being capable of installing that on Debian if built for
> Ubuntu even if all modules required are in place simply because the
> minor Python version provided doesn't meet the dependencies of the
> package is _rather_ strange. 

No, it's _Python_.  Python being one of the very few languages that doesn't
guarantee backward compatibility.  Python apps frequently _do_ need very
precise python versions.
-- 
derek