eclipse-pydev: New upstream release 1.3.13 avaible

[Kristian Rink]

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?

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? 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.

>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 this is a reason why most if not all .deb
based distributions need to have huge repositories: Because you lose the
power of tools like CPAN or Ruby Gems, because as soon as you start
using them to fetch packages, they will not integrate with your .deb
package management, thus rendering it partially unusable at least for
that very piece of application... apt is perfect for managing the "very
platform", in my opinion - all these applications that have been built
upon each other, thus largely depending upon each other. Thinking of apt
as a tool to replace CPAN, Gems, PHP Pear, maven2 and friends altogether
seems to be at least a waste of effort, IMHO.

[java modules]
> That of course is the whole problem.  There's nothing technically impossible
> about making _all_ software distribution and packaging interoperable - even
> considering different platforms.  After all, Debian & Ubuntu package up
> everything for many platforms, and they don't interfere with each other. 

Yes, but indeed the package management lives at the very core of each of
these platforms they package things for, no matter whether Debian
GNU/Linux, GNU/Hurd, Ubuntu, Nexenta Solaris or whatever .deb based
distro you could come up with - they're .deb'ed from the very kernel and
the init mechanism to the odds and ends of applications like OpenOffice
or Eclipse. Asides that, I don't really consider packaging of Ubuntu and
Debian interoperable - at least my experiences are way different here:
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. Maybe interoperability here is more than
just the package format. ;)

Cheers & all the best,
Kristian