Klik

[Rhakios]

Has anybody else had a look at this? I have just given it a quick whirl on my OpenSuse test installation and it seems to work.
Yet another possible "future for package management on Linux", or another apparently wonderful idea that goes nowhere?

[Rhakios]

Now wouldn't it help if I read everything about something before giving it a whirl and posting about it.

my own idea about klik is to use it primarily as a very efficient tool to help experienced users to testdrive development versions of KDE packages without them needing to compile themselvs, and without the distro packages needing to provide weekly snapshot RPMs and .debs (which they don't do, anyways).

So it's not really intended to be the next great thing in Linux packaging (which probably explains the lack of version control/updating capability).

[Nigel]

Still looks very interesting, though... perhaps the ideal way of packaging software for cover CD/DVDs to avoid endless postings abour dependencies ?

[M-Saunders]

"It's good, but it's not the one" to quote Roy Walker. Autopackage is still the way to go -- the effect it could have on Linux's desktop uptake can't be overstated. I'll jump for joy the day when (if) a number of distros get together and adopt Autopackage for their non-base software.

M

[Rhakios]

So, does this mean we'll be seeing autopackage files on the cover discs in future Mike?

[Rhakios]

On reflection, because of this:

Can I autopackage KDE/Qt apps?

It's possible but hard, because the C++ ABI is not stable. It was supposd to be, but then gcc 3.4 broke it yet again. Until we have a stable C++ ABI on Linux distributing binaries that link against anything other than the standard library is a bad idea. GTKmm apps are OK because you can statically link GTKmm and not suffer too badly, but Qt/KDE cannot be statically linked in a sensible fashion. We want better support for KDE apps in autopackage and know how to do it, but need somebody to step up and do the necessary legwork.

in the autopackage FAQ, then perhaps Klik, which was designed originally to distribute new versions of KDE, is a necessary complement to autopackage. Oh dear, bad thing, too many package formats again

[Nigel]

Given the amount of memory and the processor speed on modern machines, what's so wrong with statically linked binaries ? At least that way you don't end up in dependancy hell...

[Rhakios]

Well, I don't they are saying so much that it shouldn't be done, as that with Qt/KDE there are problems if you do.

[M-Saunders]

So, does this mean we'll be seeing autopackage files on the cover discs in future Mike?

Yes! Well, where they're available -- more projects are starting to make them, thankfully. It's a great relief to see an Autopackage when choosing stuff for the disc, knowing that almost everyone will be able to try the software immediately.

Some apps on 72 and 73's discs are in Autopackage format. However, the majority of projects still don't make them; hopefully this will change in time. I'm trying to think of ways to advocate Autopackage, as it'll eliminate (or at least lower) a huge obstacle to using Linux for many people...

Given the amount of memory and the processor speed on modern machines, what's so wrong with statically linked binaries ? At least that way you don't end up in dependancy hell...

True, but there's a big downside: for every little change in a library, you'd have to download all the programs that'd statically linked against it. For example, take the recent Zlib vulnerability: hundreds of programs use it, but because it's a shared library, systems only needed one update.

If every app was statically linked against Zlib, they'd all need to be updated (downloaded) again. So I think it's a good trade-off. However, I certainly agree that more programs could with a bit of static linking -- it's annoying to find some program which depends on libtinypointlessabstractionforonlyoneprogram.so.0.2.12. Developers: if it's not in a typical Linux base system or isn't widely available, statically link it in!

Oh, and use Autopackage!



Mike