aptitude is better at resolving dependencies. I switched to aptitude the day that apt-get wanted to remove libc6 and aptitude didn't.
IF you are 'holding' packages then apt-get and aptitude are NOT interchangeable.

@ DetroitLibertyPenguin: Thanks for your kind words. Glad to see that I've helped someone.

However, with the latest Pidgin version in Sid (2.5.9) and especially the coming one (2.6.0/1), there will be some additional things needed to build the Pidgin .debs. The problem is that libsilc-1.1-2-dev (required by Pidgin) has now changed names to libsilc-dev in Sid (there has also been a split in packages, but that won't affect us in the building process). Thing is, libsilc-dev is provided by libsilc-1.1-2 in Lenny as a virtual provides, and would normally be seen during the build process as provided, but because the build depends for Pidgin 2.5.9 in Sid requires a version requires, then the build dep part of the process will fail. However, there is a way around this.

The version of libsilc-1.1-2-dev (which provides libsilc-dev as a virtual provides) in Lenny is fine and will allow Pidgin to compile, but due to the stated version for libsilc-dev in the debian/control file, which you'll find in the extracted pidgin-2.5.9/ directory after you did the "apt-get -t unstable source pidgin", it'll fail because libsilc-dev in Lenny is provided as a virtual provides and as the libsilc-dev requires for Pidgin in Sid is a version requires, then that won't do for a virtual package provides (sorry if this is complicated and I'm making little sense). The control file controls the build process, in that it makes sure that the build depends and such are satisfied, and also determines the nature of the depends in the finished packages, as well as other things. The way around this problem is to edit this control file. You want to find the part of the file that says "libsilc-dev (>= 1.1.1),", and edit it to say "libsilc-dev,". In other words, delete the brackets and value after libsilc-dev. As long as you know that you have the required version of libsilc-dev and the files it provides, then you're fine doing this. As you've changed the control file to say it wants libsilc-dev as a mere provides, then your virtual provides will be accepted. Save the file, move up a directory (into the source's root) and then carry on what you normally would do with dpkg-buildpackage.

Below I give the steps as mentioned in the previous post plus the changes to control:

In 2.6.*, the changes are greater and will require a bit more editing of the control file and also the rules file (the configuration settings can be found there). You'll probably want to disable things like farsight and vv in the debian/rules file, amongst others, because they won't be satisfied in Lenny. However, seeing that 2.6.1 isn't in Sid right now, I suppose all this is moot for now (I'll come back and explain what I did... if I haven't already outstayed my welcome ).

@ Qew No, you have not overstayed your welcome and I'd be more than happy to hear what you did ;-)

Upon following your instructions I only got asfar as

[code/]
jim@LinuxBox:~/build/pidgin-2.6.2$ dpkg-buildpackage -rfakeroot -us -uc
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage: set CPPFLAGS to default value:
dpkg-buildpackage: set LDFLAGS to default value:
dpkg-buildpackage: set FFLAGS to default value: -g -O2
dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
dpkg-buildpackage: source package pidgin
dpkg-buildpackage: source version 2.6.2-1
dpkg-buildpackage: source changed by Ari Pollak <ari@debian.org>
dpkg-buildpackage: host architecture i386
dpkg-checkbuilddeps: warning: can't parse dependency ooobasis31-en_us
dpkg-checkbuilddeps: warning: can't parse dependency ooobasis31-en_us-res
dpkg-checkbuilddeps: warning: can't parse dependency ooobasis31-en_us-base
dpkg-checkbuilddeps: warning: can't parse dependency ooobasis31-en_us-binfilter
dpkg-checkbuilddeps: warning: can't parse dependency ooobasis31-en_us-math
dpkg-checkbuilddeps: warning: can't parse dependency ooobasis31-en_us-draw
dpkg-checkbuilddeps: warning: can't parse dependency ooobasis31-en_us-impress
dpkg-checkbuilddeps: warning: can't parse dependency ooobasis31-en_us-calc
dpkg-checkbuilddeps: warning: can't parse dependency ooobasis31-en_us-writer
dpkg-checkbuilddeps: warning: can't parse dependency ooobasis31-en_us-help
dpkg-checkbuilddeps: Unmet build dependencies: cdbs (>= 0.4.53) libsilc-dev libgstfarsight0.10-dev (>= 0.0.9)
dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: warning: (Use -d flag to override.)
[code]

after this i tried a couple of other things that made sense to me, but apparetnly not to dpkg-buildpackage, tyring a few other apt-gets and editing the control, no success, so i put everything back as was

It seems like everytime I feel like I actually understand something new about Linux and I'm actually learning, that I'm really not and I'm just following instructions

Basically, you haven't edited the control or rules file that I mentioned above, or haven't done them properly. After getting the source (apt-get -t unstable source pidgin), go into the source tree and find the debian/ directory. Now under that find the control file and edit the Build-Depends part of it shown below:

and replace it with this:

I've removed some of the dependencies (libfarsight and network-manager [you can keep that if you want... just make sure you download the dependency]). I also removed some of the version depends (cdbs (>= 0.4.53) is now just cdbs, libsilc-dev (>= 1.1.1) is now just libsilc-dev, etc).

Now go and find the rules file in the debian/ directory and let's start editing that. Find the part that says:

and replace it with:

These are the configuration options. I've disabled farsight, nm and vv. Again, if you want network-manager, you can keep it enabled if you've got the dependency and allowed it in the control file. Personally, I can live without.

Now you should be all set to run dpkg-buildpackage -rfakeroot -us -uc in the source directory's root.

Note that you won't be getting video support... but I don't care for that myself. If you do care for it, then I think you'll have to either update to Testing or Sid or compile a newer version of libfarsight, etc.

Also make sure you have downloaded all the needed dependencies (bar the ones you removed in the control file and disabled in the rules file)

Hope that helps a bit.

PS - If you're a perfectionist, you might want to change the version to suit your changes. For instance, I made mine pidgin-2.6.2-1+qew1. You don't need to do this, but it doesn't take long. Take a look at the dch command, especially its -v option. For instance, to get the above, I did in the source's root directory:

The opened up a vim session (might be nano for you if it's your default console editor) and I was able to edit the changlog (.deb file version changes are done via changing the changelog).

Again, you don't have to do this, but man dch might be of interest if you do. You can also just edit the changelog manually if you want with your favourite text editor, but dch is a good helper.

I would just use http://www.backports.org, and not bother with installing it from source or from Sid. Why have extra hassle, when there's a simple solution available? Backports currently has version 2.5.9-1~bpo50+1 available, which, from your opening post, would be recent enough. See the instructions for setting it up.

Because he or she might want to experiment and learn something through that hassle.

The problem with Backports is that it depends on someone creating the backport for you. That's fine in the most part, but I've found a two or three week gap on occasion between the time a security update involving Pidgin has come up in Sid and the backport finally being created. During that gap, learning how to backport the application was hassle well spent.

Still, yeah, for the most part, Backports is a good way to get an updated Pidgin and should be a first avenue to go down if wanting a more recent version of Pidgin or any other software.