Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Kremmen]

I have a server running Debian 3.0 (Woody) that I'd like to try amule on, but I've not been able to find a set of woody .deb files. The sarge installs require quite a few libs that aren't in woody.

[wuischke]

Woody? Are you serious?

You'll have to compile quite some things in order to get a halfway recent aMule version to run (and you'll want a recent version) - if you have the choice upgrade to a newer version (prefereable etch), because it's less trouble.

[Vollstrecker]

If you have no choice, it's easier to setup a chroot with a recent debian. You would have to compile more than the half of the system to get a useable toolchain. To name just a two: libc6 and gcc. I don't think you want that.

[Kremmen]

Yeah, this can be one of the problems with Linux. In the Windows world, you can still run 98SE and most current software (incl. eMule) works. In the Linux work, developers can't be bothered compiling for older versions and users are supposed to waste copious quantities of their time upgrading perfectly good systems for no particular reason. (Usually, because packages are compiled against unnecessarily new libs whose new functionality they are not using anyhow.) Of course, the whole situation could be avoided by compiling monolithic code with no shared libraries too.

The chroot idea isn't a bad one, but I don't think it's worth the effort just for one package.

[Vollstrecker]

The problem is, that the newer libs have new functions. If this functions are needed, you have to use them, or you don't get a particular feature.

[wuischke]

Windows has quite some compatibility layers (it's pretty impressive) and applications usually don't rely on system libraries, but ship their own if possible.
Still there are plently of examples of programs which do not run on Windows 9x or even 2000 anymore, because they rely on features only available in newer versions. (And this is only partly a political decision.)

aMule uses wxWidgets and there are more than enough bug fixes and new features, which are not available in older versions, to justify using the new version and dropping support for old ones.
Code which works with multiple versions gets really ugly and very complicated over the time, as you have to add mulitple versions of a routine for different API versions.

An easy example: In wxWidgets 2.6 there's a function wxImage.Ok(), in wx 2.8 wxImage.IsOk(). We need this function to check if an image was loaded properly.
Now if we want to support wx 2.6 and wx 2.8, we either have to use a wrapper function or #defines to call the right function for the library version.
This is only a very easy example, but I think you might understand what's the problem with compatibility. We don't want to win an obfuscated c++ competition, but have well understandable code.

[Vollstrecker]

For this competition would be much more neccessary. http://www.es.ioccc.org/years.html

[Kremmen]

aMule uses wxWidgets and there are more than enough bug fixes and new features, which are not available in older versions, to justify using the new version and dropping support for old ones.

Admittedly, it can get messy, but that's not such a big deal. If I'm not using wxWidgets at the moment, having to load a version of that has zero impact. In fact, the machine I'd run amule on doesn't even have X and never will. (I'd use the web module to access it from my desktop.)

Having to have newer versions of debian system libs (libc, etc) is where it becomes painful. I don't know if it would be true of amule, but I've loaded quite a few packages  with "dpkg  -i --force-all" and discovered that they worked perfectly, as libc-whateverihave is quite adequate and libc-whateverthepackageclaimstoneed has no extra required functionality.

[Vollstrecker]

Short question. Where is to problem to upgrade to a recent debian?

[Kremmen]

Short question. Where is to problem to upgrade to a recent debian?

More important question is why would I want to do something which could take days, when I don't need to for anything else? It's a significant amount of work. Loading one package takes 2 mins.

Doing an upgrade takes hours, when you include making full backups beforehand. Also, it's my main file server. Everything that needs it also has to stop for that period. Then there's the risk factor. Existing command output can change. ... as Linux developers tend to change things, willy-nilly, just because they can. eg. From early woody to later, the length of  'ls -l' output changed. Any scripts running ls and expecting the output in a particular column broke. To ensure that things like that don't silently happen, that means testing every single customised script on the machine to see if it's been broken by the upgrade. This sort of thing can take days.

However, I might upgrade to sarge sometime, since this appears unlikely to change anything too major.