Linux Format forums

Re: RE: Klik

M-Saunders — Tue Sep 20, 2005 10:00 am

Author: M-Saunders

Posted: Tue Sep 20, 2005 10:00 am

Rhakios wrote:

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...

Nigel wrote:

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

RE: Klik

Rhakios — Mon Sep 19, 2005 10:12 pm

Author: Rhakios

Posted: Mon Sep 19, 2005 10:12 pm

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.

RE: Klik

Nigel — Mon Sep 19, 2005 10:04 pm

Author: Nigel

Posted: Mon Sep 19, 2005 10:04 pm

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...

RE: Klik

Rhakios — Mon Sep 19, 2005 9:17 pm

Author: Rhakios

Posted: Mon Sep 19, 2005 9:17 pm

On reflection, because of this:

Quote:

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

RE: Klik

Rhakios — Mon Sep 19, 2005 9:13 pm

Author: Rhakios

Posted: Mon Sep 19, 2005 9:13 pm

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

RE: Klik

M-Saunders — Mon Sep 19, 2005 12:40 am

Author: M-Saunders

Posted: Mon Sep 19, 2005 12:40 am

"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

RE: Klik

Nigel — Sun Sep 18, 2005 8:33 pm

Author: Nigel

Posted: Sun Sep 18, 2005 8:33 pm

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

RE: Klik

Rhakios — Sun Sep 18, 2005 7:53 pm

Author: Rhakios

Posted: Sun Sep 18, 2005 7:53 pm

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

Kurt Pfeifle wrote:

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).

Klik

Rhakios — Sun Sep 18, 2005 7:07 pm

Author: Rhakios

Posted: Sun Sep 18, 2005 7:07 pm

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?