Gimp 2.4 to Gimp 2.6 for a relative newbie

[nadir]

chew a bit on it and try tomorrow.
you might comment the lines bout cds with a
#
in front of it. you also might completely remove them. good luck and good sleep

ps: i edited my last post: i agree that a complete upgrade to squeeze is the better option. but its up to you.

[stevepusser]

Ideally, we would like to maintain a Lenny compatible system, and mixing upstream testing and unstable repositories can lead to a broken system if you aren't really careful and know exactly what you are doing.

Another, usually better solution, is to take the debianized source code from upstream, and rebuild it against the headers (also called includes or -dev packages) of the Lenny versions of the libraries that Gimp uses. Some programs end up being impracticable, some very difficult, and some absolutely easy. I am pleased to say that gimp-2.6.8 from Sid turns out to be very easy, so easy that I don't know why it's not in lenny-backports already.

I am running a "pure" Lenny plus lenny-backports installation in a virtual machine, but my laptop can't support a 64-bit VM, so I just have a 32-bit build. I took a look at the dependencies, and as far as I can tell, you don't even need lenny-backports.

Link: https://sites.google.com/site/stevosfil ... ebs.tar.gz

I put a terminal installation README file inside. I'd also recommend gdebi as a GUI for deb files, since it will preinstall missing dependencies.

I also have the source files, which have only the changelog updated from the Sid version. If someone could build the 64-bit version, that would be nice. Let me know if you need them.

[Soul Singin']

Just chiming in to second Steve. Backporting is much safer than mixing Testing and Stable.

Mixing Testing with Stable does not always cause immediate breakage, but sometimes it does. So if you do not have a strong knowledge of package management, pinning, etc., then you should not be running a mixed system.

Forgive me for channeling RickH, but if you're using Synaptic, you probably do not have the necessary knowledge of package management.
.

[saulgoode]

Not to distract from the Debian backporting discussion too much, I thought I'd throw out a "safe" way to compile GIMP from source and not have it interfere with another installed version, or with Debian package maintenance.

After downloading and extracting the source tarball for version 2.6 (latest is 2.6.8), change into the extracted directory and run the following command:

Code: Select all

LDFLAGS="-Wl,-rpath /opt/gimp" ./configure --prefix=/opt/gimp

Hopefully, all of the dependencies will be met. If not then you will have to install them; either from a Debian backports repo or by compiling those dependencies using the same configure command. (The latter choice will keep your Debian system "pristine".)

The --prefix option instructs 'make' to install all of the compiled files under the /opt/gimp directory; keeping them separate from all of the APT-handled files. The LDFLAGS setting instructs the compiler (actually the runtime dynamic linker, /lib/ld-linux.so.2) that it should first try to link libraries from the /opt/gimp/lib directory before searching the normal system library paths (/lib, /usr/lib, and the directories listed in /etc/ld.so.conf). This not only ensures that the libraries will be found (should no other version of GIMP be installed), but that libraries installed by other versions of GIMP will be ignored.

Once configure has finished, you can continue by running 'make'; and then running 'make install' as root.

Once installed, you can run your custom version of GIMP with '/opt/gimp/bin/gimp' -- though you will likely wish to create a link placed in your user's default search $PATH and using a unique command name. For example:

Code: Select all

ln -s /opt/gimp/bin/gimp /usr/bin/gimp26

Installed in this manner, you will be able to later remove all traces of the program from your system by merely deleting the /opt/gimp directory tree. Your package manager will not be aware of the existence of this version, so any necessary maintenance (updates, security patches, etc) must be handled manually.

[ElmerFishpaw]

Steve,Saul goode....soul....At work now, and out tonight. I will put on a pot of coffee tomorrow afternoon and have at it! I appreciate and am very thankful for the help here.
I will get this done somehow. I'll keep trying and will definitely learn something1

[Soul Singin']

Not to distract from the Debian backporting discussion too much, I thought I'd throw out a "safe" way to compile GIMP from source and not have it interfere with another installed version, or with Debian package maintenance.

@ ElmerFishpaw -- Saul provided very good advice in his post. I generally discourage people from using the make install method, but if you are going to use that method, then follow his instructions. They're excellent.

Before choosing a method however, you should do two things.

• You should read Appendix B -- The Basics of Package Management. (It would also be a very good idea to read the APT HowTo, but I'll admit that that APT HowTo is a little bit too long for the impatient).
• After you have read about package management, you should read my HowTo Build a Package from Source the Smart Way.

Once you have read those documents, you will understand the different methods suggested by Steve and Saul (i.e. backport vs. make install). And if you understand those differences, you will be able to make a well-informed decision.
.

[stevepusser]

Yes, and as far as I can tell, Gimp 2.6.8 is perfect as a first attempt. You should have no trouble building a deb on a vanilla Lenny install. I took a look at the build-depends in debian/control, and the maintainer is making an effort to keep the source as easy to backport as possible. That is, the build-depends have alternates that will work on either Sid or Lenny, and there are no cute tricks in the debian/rules file (the actual script that compiles and packages the program) that break the build in Lenny. I could name some other upstream packages...yeah, you there, Gdebi 0.5.9.2. It took me a week to get you to build on the Lenny python2.5. (OK, someone that actually knows code could have done it in a minute)

[ElmerFishpaw]

http://tuxarena.blogspot.com/2009/03/ho ... 66-in.html

OK....I'm going to try the steps in this webpage. #4 confuses me. I don't understand what's meant and how to do step 4.

[ElmerFishpaw]

OK...did all this....how do I delete 2.4 ?
These instructions worked (or at least ran a ton of things in the terminal) GIMP 2.6 is in my home folder. I need to make it open now.

[Soul Singin']

http://tuxarena.blogspot.com/2009/03/ho ... 66-in.html

OK....I'm going to try the steps in this webpage. #4 confuses me. I don't understand what's meant and how to do step 4.

Step 4 was:

Code: Select all

./configure
make
make install

OK...did all this....how do I delete 2.4 ?
These instructions worked (or at least ran a ton of things in the terminal) GIMP 2.6 is in my home folder. I need to make it open now.

Congratulations. You just compiled a package from source the <<insult deleted*>> way.

You got problems? Figure it out yourself.

Why should we spend time writing detailed instructions if you're just going to ignore them? ..



* Insult deleted at moderator's request.

[stevepusser]

OK...did all this....how do I delete 2.4 ?
These instructions worked (or at least ran a ton of things in the terminal) GIMP 2.6 is in my home folder. I need to make it open now.

Sigh...actually, backporting is much, much, much, much easier than any random webpage "configure, make, make install" procedure you will find. The upstream Debian source files are very often heavily patched to fix bugs or incompatiblities with Debian, and you miss all that with the raw source, plus they include instructions to let the new version upgrade gracefully over the older version.

Seriously, to backport things, I do a one time install of debhelper, devscripts, dpkg-dev, build-essential, fakeroot, and pbuilder. Then I go to packages.debian.org and pull off an upstream version, downloading the source files on the right side of the page into a folder. I open a terminal in that folder and run

dpkg-source -x <name of .dsc file>

I hate typing, so tab-complete comes in handy here to provide the name of the file (but I now have a right click context menu that extracts the source from .dsc files)

Then I enter the extracted source folder and run as root:

/usr/lib/pbuilder/pbuilder-satisfydepends

which creates and installs a dummy package that depends on the build-depends of the upstream version, so it pulls them in automagically. If this works, great; otherwise you have to open the hood (the /debian/control file) and tinker with things. Follow Soul's guide and update the changelog, then rebuild the package per his guide. As is often the case with Debian, Gimp is split into several packages; the standard install order would be the -data or -common packages, then the lib<package> files, and finally the <package_name> deb, in this case, gimp-2.6.8-something.deb.

New versions of applications often add build-dependencies that are not apparent, or are missing from older guides found on the web. Do yourself a favor and do it the right way.

[ElmerFishpaw]

Thanks everyone! I appreciate all of Your time and effort. Very sincerely. In my learning of Linux, this was just beyond what I was capable of ......yet.
The detailed instructions were just beyond what i understood and beyond what I knew about doing this. You all took time to try and help, and again, I
really do appreciate that. Thank You.

[Soul Singin']

A moderator has admonished me for using a derogatory term to describe the way you compiled GIMP, so I'm going to take a step back and try to look at things from your perspective.

In my learning of Linux, this was just beyond what I was capable of ......yet.
The detailed instructions were just beyond what i understood and beyond what I knew about doing this.

OK. I think I can understand that.

But you have to understand that the details are important !!! That horrible TuxArena tutorial is "simple" because it omits all details, such as the fact that the make install command will overwrite anything that gets in its way, including important system libraries.

That's why Saul took the time to describe a method of installation that would "keep your Debian system 'pristine'" and that's why Steve took the time to explain backporting to you. So please:

• Read Appendix B -- The Basics of Package Management and read the APT HowTo.
• Then read my HowTo Build a Package from Source the Smart Way.

Once you have read those documents you should know enough to avoid doing dangerous things to your computer.
.

[Soul Singin']

OK...did all this....how do I delete 2.4 ?

This is precisely the reason why Steve and I recommended that you backport the package (i.e. build DEBs of the newer version of GIMP for Debian Lenny). A properly built DEB will:

• make sure that all package dependencies are met
• prevent you from unknowingly overwriting system files
• make APT aware of the package's presence.

By contrast, the make install routine that you used overwrites any file that gets in its way. And because the guy who writes the TuxArena blog did not bother to discuss the ./configure options, you do not even know where the package was installed.

For your sake, I hope the package defaulted to /usr/local/. If on the other hand, it installed to /usr/, then GIMP 2.4 is completely destroyed. Hopefully, that's the only package that was destroyed.

Oh, and by the way, did the TuxArena blogger tell you that if you ever want to run make uninstall on GIMP 2.6, then you will have to keep the compiled version in your $HOME directory? (even if it consumes 20 GB of space!)

That's why Saul spent time explaining the --prefix=/opt/gimp option to you. So that you could delete /opt/gimp in one stroke and not have to worry about destroying other packages.

To quote from my HowTo Build a Package from Source the Smart Way (which you didn't read):

Finally, there's the make install routine. make install should be your absolute last resort. You should NEVER use it unless all other options have failed and you should ONLY use it IF the package you want to build is of mission critical importance.

The make install routine is the most primitive method of building a package from source and has absolutely no concept of dependencies or package management. There's a reason why GNU/Linux distributions use package managers like APT or RPM. And that reason is to get as far away from make install as possible.

So if you're going to use make install, then at least use it intelligently. Do NOT blindly follow the lemmings running off the cliffs of the internet.

.

[Soul Singin']

Link: https://sites.google.com/site/stevosfil ... ebs.tar.gz

Thanks Steve! That works great! As a thank you, I produced the image below:

towork.png (112.66 KiB) Viewed 5135 times

Sorry. My GIMP abilities are rather limited.
.

[stevepusser]

Hah! Mine are probably worse.

I should message whoever's running lenny-backports and ask them to add the new Gimp, anyway. I have no idea why such a marquee program isn't there already.