GParted 0.0.9 released

next release will be 0.1.0 and i think i'll drop the last zero.

Why not 0.10 ?

The third point column expresses fractional fixes, but when the second column is 0, it looks like extreme alpha software. There's nothing wrong with using only two columns, especially if the application isn't a kernel, an office suite, or a desktop environment.

That is the wrong way to count dependencies. ldd reports the entire dependency tree as a single list. In other words: ldd also reports the dependencies of the dependencies (of the dependencies of ...etc...). The correct way to find out direct dependencies is:
objdump -p foo | grep NEEDED

[hongli@hatsumi ~]$ objdump -p /usr/bin/nautilus | grep NEEDED | wc -l
43

Quite a difference from your 76, isn't it?

No. It just means that the other 33 are not direct dependencies of Nautilus, but rather indirect dependencies. But that does not mean that indirect dependencies should always be counted. Counting indirect dependencies is a bad thing because those are indirect dependencies. Let's say your app uses gtk, and gtk uses libfoo, and you count libfoo as dependency. But what if some day gtk decides to remove support for libfoo? It will no longer depend on libfoo, but your app still depends on libfoo even though it doesn't really need it, thus making life harder for users!
We have done a lot of research on binary compatibility and bogus dependencies. They can cause a lot of pain.

Why is introducing new dependencies a problem? I'd say making GNOME depend on gtkmm and glibmm is a good thing, since more gtkmm apps will have a higher installation success rate if more users have gtkmm preinstalled.

It's easy to point fingers at distributions, but things just don't work like that in the real world. When Joe wants to use your app, he wants to use it. He does not care who ships the dependencies, as long as he can use the apps. Telling him that his distribution sucks because it doesn't install gtkmm by default really doesn't solve his problem.

Seriously if the distribution (who's job it is to select packages to be installed) is not responsible for installing joe sixpack's copy of gtkmm then who's job is it? Gnome makes a gnome-bindings package with bindings to allow one to use lots of programming languages with Gnome. This package is released at the same time as the desktop at platform packages. Distributions choose whether or not they want it in their distro. If a distribution chooses to not put them in then it DOES suck, pure and simple. What gnome depends on is irrelivent. If a distribution wants to put Konquerer with Xfce panel with Metacity and call it Gnome they can; this is called "packaging" and it's what distros do a lot of. Nothing Gnome could do would change this, short of taking out international trademark protection on the name Gnome and suing the arses off distros that don't ship gtkmm as default.

Next time you want to take up the cause of the mythical joe sixpack, realise that nomatter how much you winge and object, it won't do any good if you blame the wrong people. It seems that attributing someone's problems to their distro of choice has become the linux world's equivalant to telling little timmy that he will never be able to be a fireman because he's in a wheelchair. It's politically incorrect but downright obvious.

You are right in one thing, in the real world, losts of people get stuck with the blame they don't deserve. This is called scapegoating. However scapegoating never achieved anything. How about you stop trying to play the grizzled and wize graduate of the "school of life" and start actually thinking about how this problem can be solved and where it can be solved. Being an ignorent git by citing what you see as the facts of "the real world" when there is a real problem won't help anyone.

> How about you stop trying to play the grizzled and wize graduate of the "school of life" and start actually thinking about how this problem can be solved and where it can be solved.

I believe FooBarWidget has in fact been thinking about this. Have a look at the Autopackage project and their quite clever solutions to problems created by the ignorance and arrogance of various parties.

Autopackage tries to be a solution to the problem that everyone's distro is different, they attempt to provide another package management system that is supposed to be universal. However Autopackage falls short for the same reason as the other package managers do, because of the fact that base installs of linux arn't identical. Even in its own FAQ, Autopackage concedes that it needs a "desktop linux platform" to work i.e. the base installs of Linux must be the same which they are not currently and can not be without a lot of hard work between the distros.

So how then can the problem be solved? Well, first we have to ask "What is the problem?". The problem is that linux software cannot assume a consistant system so packagers must compensate for this by making very different packages for only slightly different systems. This takes a lot of work and can lead to a lot of incompatibility and effort duplication. An .rpm, .deb, .ebuild or Makefile (ports) can be made in seconds with automated tools on the same system, assuming that the core dependancies are all the same. Theoretically they could all be made at the same time automatically so the packages are not the problem. The problem comes for the hours of testing, checking, patching and configuring a package must go through to fit onto a system. Autopackage addresses the package file multiplicty un-problem but does not attempt to address the fact that systems are naturally incompatible and inconsistant. If this was solved, then the packaging problems would simply melt away.

The current generation of package management systems are brilliant (even the much malligned Yum). Every windows user I have demonstrated Apt to have been utterly astounded by its simplicity and ease, to many it is the best feature of the entire operating system. One of my friends started using linux souly because of Apt. I personally beleive that those who complain about the state of package management under linux are invariably the ones who have never used it or don't understand it. Autopackage may appeal to those people who believe that all software must be installed after recieving an self-extracting package off a website just like was done under windows; with that in mind, Autopackage becomes perfection. However to people like me, who really love repository driven package management systems, it becomes just another system that is good, but not quite as good as the one I am using. Autopackage can never be a cure-all like it is touted as being, while people like me find it less convenient to use because of its lack of a 3 click-0 type install.

Once again, FooBarWidget picks the wrong scapegoat. Packages are held to blame when it is really the disto's incompatibility that is at fault. Autopackage cannot address the real issue until its designers work out what that issue is. We have more than enough package managers, some of them brilliant. What we need now is some core standardisation, not just another competitor in the wide world of packages.

"Autopackage tries to be a solution to the problem that everyone's distro is different, they attempt to provide another package management system that is supposed to be universal. However Autopackage falls short for the same reason as the other package managers do, because of the fact that base installs of linux arn't identical."

Sure, distributions are different. But there are enough similarities in the *desktop* platform that make it possible to run desktop application binaries on many distributions. Autopackage isn't some works-in-theory-0.1-project, it's actually *usable* and *works*. It works right now, as in today. Take a look at our positive user feedback. We aren't selling hot air, we have actually put efford into making that its possible.

Actually, one of the reasons why there are problems with running binaries on different distributions is that many developers think its impossible. That just contributes to the problem, because nobody will put efford into solving that. But at autopackage we have shown that it is possible (in practice!), and we want to encourage people to start caring about cross-distribution software installation.

"Even in its own FAQ, Autopackage concedes that it needs a "desktop linux platform" to work i.e. the base installs of Linux must be the same which they are not currently and can not be without a lot of hard work between the distros."

You misunderstood that. The FAQ says that a "desktop platform" is a good idea because it makes life easier for developers, not that it needs one in order to function. Again: autopackage works, today.

Anyway, back to the "desktop platform" thing. The idea is that the developer can say "my app depends on Desktop Platform 1.2" instead of "my app depends on gtk 2.2, libxml 2.0, glibc 2.3, libfoo 5.0, libbar 6.0, libwhatever 0.5, etc etc etc".

Frankly I don't feel like replying to your points, as I've already replied to them many, many, many, many, many times. *sigh*. Some day I'm going to write an article or an updated FAQ to dispel of those myths once and for all.

Sure, distributions are different. But there are enough similarities in the *desktop* platform that make it possible to run desktop application binaries on many distributions. Autopackage isn't some works-in-theory-0.1-project, it's actually *usable* and *works*. It works right now, as in today. Take a look at our positive user feedback. We aren't selling hot air, we have actually put efford into making that its possible.

I realise that autopackage is a working piece of software, however there is a huge leap between having the software working and having the system working at a state where autopackage accomplishes its task in the way that will save the world. Autopackage needs enough packages to be created for dependancies to be settled. This is not the case yet.

Frankly I don't feel like replying to your points, as I've already replied to them many, many, many, many, many times. *sigh*. Some day I'm going to write an article or an updated FAQ to dispel of those myths once and for all.

The very fact that you start off by suggesting that gtkmm should be included by default so that people won't be afraid to install apps based on it is very strong evidence that you don't personally quite understand what package managers do and should do. When I install a gtkmm app with apt, it installs gtkmm without any user intervention, I don't even know its doing it. The autopackage documentation makes a clear distintion between the core operating system (which autopackage doesn't administer) and the user applications that it does. But with linux, there is no difference. There are just packages and packages that depend on other packages. Gtkmm isn't part of Gnome, gtkmm is just a package, it's a package that depends on libgtk2 and libstdc++ and that gparted depends on. With a real package manager who cares if it is installed by default with gnome? It will be installed when something needs to use it and that's all anyone cares about.

Before you get out there to make sure the world understands autopackage, make sure you yourself understand the problems at hand and the solutions we have today.

"The very fact that you start off by suggesting that gtkmm should be included by default so that people won't be afraid to install apps based on it is very strong evidence that you don't personally quite understand what package managers do and should do."

Oh thank you for making such a big assumption about who I am and what I do(n't) understand.

My point is that not all distributions package gtkmm or $RANDOM_DEPENDENCY, which means that you can't even apt-get them. If gtkmm is a required part of GNOME, then that would force even the sucky distros to include them, thus making life easier for more users.

"The autopackage documentation makes a clear distintion between the core operating system (which autopackage doesn't administer) and the user applications that it does. But with linux, there is no difference."

The point is that there should be a difference. It is exactly because many people treat like they're the same, that problems occur.

You still don't understand what I'm saying. I'm not saying that dependency problems can't be solved by apt. I'm saying that they are not the holy grail like many people think they are:
1. Not all distributions have everything in their repository.
2. Even if they have something, it may not be up-to-date.
3. Some packages are in the repository are just plain broken.

Explanation for point 1:
Take for example Mono (and for the sake of discussion, let us forget that .NET is created by the 3v1l Micro$oft). I don't know whether Debian/Ubuntu have Mono in their repositories, but Fedora 4 definitely doesn't. Note that Fedora is a popular distribution. So what is the user going to do if he can't type 'yum install mono'?
Obviously, *someone* has to create a package so he can install a third party, not-part-of-the-distro package (or compile from source, but that sucks and you can't expect your mom to do that). Preferably, a package which works on multiple distributions. Uh oh... doesn't that sound awfully familiar?

Explanation for point 2:
Firefox 1.5 was released yesterday (or so Slashdot says). Today, I type 'yum check-update'. Nope... no Firefox 1.5 in the list. So what am I supposed to do if I can't type 'yum install firefox-1.5'? Hm, it certainly would be great if the Firefox developers provide their own package that can be installed anywhere. Hm, wait a minute...

Explanation for point 3:
Take for example Fedora's DirectFB package. Today I typed 'yum check-update'. It says there's an update for the DirectFB package. I type 'yum install directfb' and this is what I get:
Resolving Dependencies

--> Populating transaction set with selected packages. Please wait.
---> Package directfb.i386 0:0.9.24-4.fc4 set to be updated
--> Running transaction check
--> Processing Dependency: libsysfs.so.1 for package: directfb
--> Processing Dependency: libdirect-0.9.so.22 for package: xine-lib
--> Processing Dependency: libfusion-0.9.so.22 for package: xine-lib
--> Processing Dependency: libdirectfb-0.9.so.22 for package: xine-lib
--> Processing Dependency: libdirectfb-0.9.so.22 for package: mplayer
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package sysfsutils.i386 0:1.2.0-4 set to be updated
--> Running transaction check
--> Processing Dependency: libdirect-0.9.so.22 for package: xine-lib
--> Processing Dependency: libfusion-0.9.so.22 for package: xine-lib
--> Processing Dependency: libdirectfb-0.9.so.22 for package: xine-lib
--> Processing Dependency: libdirectfb-0.9.so.22 for package: mplayer
--> Finished Dependency Resolution
Error: Missing Dependency: libdirect-0.9.so.22 is needed by package xine-lib
Error: Missing Dependency: libfusion-0.9.so.22 is needed by package xine-lib
Error: Missing Dependency: libdirectfb-0.9.so.22 is needed by package xine-lib
Error: Missing Dependency: libdirectfb-0.9.so.22 is needed by package mplayer
There you go, a broken package in Fedora's repository. My point is: not all packages in the repository works. The repository isn't the holy grail.

If you think "Fedora sucks", then let me remind you that Fedora is a popular distribution and has many users. You can't just tell the thousands of them to use $YOUR_FAVORITE_DISTRO.

These problems aren't limited to just Fedora. Other distributions have similar problems.

Conclusion: you can't rely on the distribution to solve every single packaging problem. Autopackage is supposed to help solving the problems that current package managers do not solve. If the developers themselves also distribute their own, multi-distribution packages, then what harm is done to the Linux community? Why wouldn't it be a good thing to provide the user the choice to use the developers' own packages? Nobody's forcing you to use autopackage if you don't want to. Isn't Linux all about choice?

> My point is that not all distributions package gtkmm

Which ones? Let me at 'em.

How about you stop trying to play the grizzled and wize graduate of the "school of life" and start actually thinking about how this problem can be solved and where it can be solved.

Being a little inflammatory don't you think? Just so you know, FooBarWidget happens to be one of the people working on Autopackage, so he IS trying to do something about the dependency problem. And you are a little offtopic anyway. The original poster asked a simple question: "Can gparted be included with Gnome System Tools." The answer was that there would be some resistance due to the requirement for gtkmm. FooBarWidget mentions that it would be a good idea to include gtkmm anyway...and then this whole rant about how it is up to the distributions to include bindings.

You are right, in general, if the distributions don't ship it you can't really blame Gnome. But the point of the thread was whether gtkmm would be an acceptable dependency within Gnome, for inclusion of gparted. Given the number of gtkmm applications that people might want to use, it probably is. Of course, you can also make the same argument for Mono....

Ubuntu 6.04 will have something like this. A live CD with gparted, and an "express installer" also using gparted.

And the current ubuntu already has gparted on board. I find it a very nice tool to have.