eclipse-pydev: New upstream release 1.3.13 avaible

Kristian Rink kristian at zimmer428.net
Thu Feb 21 20:25:29 UTC 2008


Derek Broughton schrieb:

[general package management]
> 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.

Ever considered the idea that freedom of choice in solutions is a good
thing? ;) Isn't that what we here are trying to do by promoting people
to choose (Ubuntu GNU/)Linux rather than a "de-facto standard" platform
to run on their machines? In my eyes, here, interoperability would be
important, but interoperability doesn't necessarily mean a homogenous
technology.


[...]
> 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.

I strongly disagree with having maven listed in a row with apt and rpm
in merely being a tool for developers in order to ease dependency
management in projects maintained by distributed developers. Example: A
lot of internal java dev teams I know of still deal with dependencies by
creating "dummy" projects just containing required .jar files and
dumping these to the local SVN repository. Hardly a desirable way to do
so even given that SVN does way better about binary files than CVS.
maven is a good way of doing so, as it does integrate well with most of
the Java IDEs across all platforms, it's reasonable easy in its
configuration, and, possibly more important, building artifacts is a
breeze, especially compared to building valid .deb packages which still
then and now seems black art to me. :)


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

A situation I have seen earlier on Debian-stable quite often: A module
in question is in the repos but way too old to do a given task. Two
options: (a) wait for a stable debian release to contain an updated
version, (b) install it via CPAN and possibly see it erased in course of
the next dist-upgrade (as, as you stated so well, apt doesn't care about
code installed any other way), or (c) somehow mess around with apt to
keep packages from being upgraded. If you're a hardcore perl user, CPAN
is your natural environment, is where you're likely to feel home
(especially if you're a contributor of perl modules). Not being able to
effectively use these tools without breaking the package management of
your distribution is a bad thing.

Another example on that, to illustrate my point of view: I need to have
a tool to get a job done. Remembering my first attempt of manually
building GNOME 2.0 and early nautilus from sources, I suffered, as,
starting with libgtk+ and friends, I had to fetch a h**l of dependencies
and dependencies of dependencies and configure and build them in the
right order altogether. Though this way I learnt quite some things about
the projects structure and Unix build mechanisms in itself, I don't want
to do so again. Here, package management helps as "./configure && make
&& make install" doesn't have no notion at all of dealing with (missing)
dependencies (or even missing headers of dependencies, that is). Here, a
well-crafted package management (like apt) is beneficial as it keeps me
from having to deal with all these things on my own.

In Eclipse, however, things are different. Here I do have a package
management I can make use of, and even one which works everywhere. No
matter whether I work on my Ubuntu notebook or, once in a while, on a
Windows XP box at work, I just can launch the Update Center and install
the very module I need without second thought. Maybe the package
management is not as powerful or sophisticated as apt, but it does the
job, so no second tool is required here. Throwing in apt actually _is_
this second tool trying to override a solution already in existence, and
(no offense) it's not rather smart at doing so. Eclipse has not been
built to live with apt. If Eclipse is packed to be installed via apt,
_apt_ should be aware and honour things that happen inside Eclipse's
package management, not vice versa IMHO. :)

> Maven seems to mostly do this - but dependency checking is either weak, or
> the project I'm working with got it wrong :-)  

Well... what kind of features do you miss about that, so far? Looking at
our internal projects involving maven2 (and there are quite some of
them), I yet have to find a maven2 shortcoming, apart perhaps from
having an OSGi-like notion of "module lifecycle" (requiring artifacts
not just to be added but also to be started and exposing its services...).

Cheers & best regards,
Kristian







More information about the ubuntu-users mailing list