Upgrading from source a package depended by many many things

[the dsc]

Hello. I was trying to install on my debian lenny (which recently became the stable version) the latest gimp, 2.6.6, from source, which depends on newer versions than I have of glib and gtk+.

Both would have to be installed from the source too, so I did. Glib has to be the first, as gtk+ depends on it. Everything pretty much fine with its instalation, despite of the fact that I still have an older version of it, installed via deb package, and it confuses gtk+' "configuration", which recommends to remove it. But If I mark it to removal (with synaptic), then half of my system would go away with it. Apparently, everthing with a graphic interface, from KDE to openbox.

What are my options?

Can I use some dpkg or apt-get command line to force the removal of the old glib only? (Hoping that the things that depend on the old one would just start using the new one, already installed, which may not be the case) I think it may require some painful individual analisation of each compromised package, whether they'd be compatible with the new glib or depend on an older version. Plus I may have to figure some way to "tell" these applications that there is a glib installed after all.

Other option I can imagine would be to upgrade to sid, which should have everything more closer to the newest versions... but I'm somewhat reluctant, as I've never dealed with a "real" testing version, when I installed lenny it was almost stable already, I think.

And the last one would actually to remove everyhing it tells me to remove and reinstall. In this case, I probably would have to compile everything from the source too, right? Or just the installation from the deb packages would work?

(Well, I could theoretically do nothing as well ... or at least try not so brand-new versions of glib and gtk, maybe even gimp... if that would really help.... I'm not sure)


Sigh... I got to learn how to backup a highly-customized installation to do all sorts of experiments and have some dry land to go if the whole thing sinks.





Hey, another thing that occurred me just after I posted... I think that may be possible to create a package, then update from it.... I got to investigate this whole package-making deal... I'm almost sure such thing exists...

[MikeTbob]

Why don't you use the package manager to solve this mess for you? It will probably not remove the old glib or gkt, but install them side by side. If nothing else, use the package manager to install everything but GIMP, because you want the newest version right?

[the dsc]

Why don't you use the package manager to solve this mess for you? It will probably not remove the old glib or gkt, but install them side by side. If nothing else, use the package manager to install everything but GIMP, because you want the newest version right?

Well, unless I'm missing something, it's the package manager that is doing this mess, in a way. Not quite, only that it is not actually designed to do what I was trying to do. What people "should" do is to stick with whatever is available in their "version", in their proper repositories and not try anything fancy, unless one is experienced enough to know.



But actually I sorta used the package manager to solve everything in a way I didn't thought before. I just added the repositories from "squeeze", which is the new "testing" (not sid, as I thought) and upgraded gimp. Now I have to edit some configuration file that will keep it this way, plus remove the squeeze repositories to avoid mixing too much with squeeze. Way simpler than the other theoretical possibilities, which I'm not even certain that could work...


I had actually done something similar once with etch and lenny, but I forgot I did it

[MikeTbob]

Well I am sure you are right about setting an option that will keep your repos from mixing too badly. I don't know enough about Debian to give you any valuable hints here. You sound experienced enough that I figured you would probably solve this on your own. Just be sure to take extra precautions when you mix repos, it can lead to a really big mess.

[i92guboj]

Hello. I was trying to install on my debian lenny (which recently became the stable version) the latest gimp, 2.6.6, from source, which depends on newer versions than I have of glib and gtk+.

Both would have to be installed from the source too

Why? Is the problem that debian doesn't have devel packages for recent gtk and glib versions?

, so I did. Glib has to be the first, as gtk+ depends on it. Everything pretty much fine with its instalation, despite of the fact that I still have an older version of it, installed via deb package, and it confuses gtk+' "configuration", which recommends to remove it. But If I mark it to removal (with synaptic), then half of my system would go away with it. Apparently, everthing with a graphic interface, from KDE to openbox.

And now there comes the big question. How did you compile this? Was you at least careful enough to use a different --prefix for the packages you installed by hand so they don't interfere with the package manager?

[quote]

Can I use some dpkg or apt-get command line to force the removal of the old glib only? (Hoping that the things that depend on the old one would just start using the new one, already installed, which may not be the case) I think it may require some painful individual analisation of each compromised package, whether they'd be compatible with the new glib or depend on an older version. Plus I may have to figure some way to "tell" these applications that there is a glib installed after all.

Which leads me to believe that you simpley threw everything into the system without any care. I'd do this if I were you, and please, understand that at the current state of things I can't guarantee that this is going to work:

• make uninstall EVERYTHING you installed by hand
• reinstall everything using your package manager, make sure that your system works as it is using only the stuff provided by your official package manager and packages
• now, ./configure --prefix=/usr/local all the packages you want to install by hand and then make and make install them again

Now you should have a working debian installation, and whatever you wanted to compile by hand will be into /usr/local, well apart from your main system. If you don't like /usr/local you can do this into a directory in your home dir as well.

[the dsc]

Yes, I did compiled it "over" the installed deb package without worrying about a different prefix or anything. I thought it would just overwrite, but there was some sort of mess that I don't quite understand. The second compilation (actually ./configure) complained about detecting different versions, and recommended something I don't recall. Nothing catastrophic happened, apparently (I'm not trying to minimize the potential dangers of doing this, just reporting). The only thing I noticed was that fantasdic didn't work, with some message related with ruby and/or glib, but I solved by upgrading some more packages.

Then I uninstalled glib, which was the one I installed "by hand", maybe I did something more, and everything works fine.



Before closing the topic, I just want to stress the potential dangers of mixing different releases... I recall that once I got into a lot of trouble just because I wanted deja vu sans serif condensed in debian etch, then I tried to install from lenny. I didn't thought it even could cause any problem at all, since these are fonts, not programs, would be more or less like having trouble by saving some png or other "static" file from other release or somewhere else. But it's more complicated than that, I think it has to do with the .deb scripts. And today I realized something somewhat related, pcmanfm won't install without previously uninstalling libfam, despite of having it listed as a dependency (and I'm with the correct version). And many many things depend on libfam... so if one does not pay much attention could end out uninstalling lots of KDE-related software and maybe other things when just attempting to install a simple file manager. So even within a single release this can be somewhat tricky. And this was supposed to be the more newbie-friendly part (well, actually it is, but attention cannot be discarded).

Not that compiling from the source is some sort of homeric task, I've done it many times, I don't want to scary anyone either.


Thanks, both of you.