Klik

Discussion topics, Linux related - not requests for help

Moderators: ChrisThornett, LXF moderators

Klik

Postby Rhakios » Sun Sep 18, 2005 6: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?
Bye, Rhakios
User avatar
Rhakios
Moderator
 
Posts: 7634
Joined: Wed Apr 06, 2005 11:18 pm
Location: Midlands, UK

RE: Klik

Postby Rhakios » Sun Sep 18, 2005 6: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).
Bye, Rhakios
User avatar
Rhakios
Moderator
 
Posts: 7634
Joined: Wed Apr 06, 2005 11:18 pm
Location: Midlands, UK

RE: Klik

Postby Nigel » Sun Sep 18, 2005 7:33 pm

Still looks very interesting, though... perhaps the ideal way of packaging software for cover CD/DVDs to avoid endless postings abour dependencies ?
User avatar
Nigel
LXF regular
 
Posts: 1141
Joined: Fri Apr 08, 2005 8:03 pm
Location: Gloucestershire, UK

RE: Klik

Postby M-Saunders » Sun Sep 18, 2005 11:40 pm

"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
User avatar
M-Saunders
LXF regular
 
Posts: 2893
Joined: Mon Apr 11, 2005 12:14 pm

RE: Klik

Postby Rhakios » Mon Sep 19, 2005 8:13 pm

So, does this mean we'll be seeing autopackage files on the cover discs in future Mike?
Bye, Rhakios
User avatar
Rhakios
Moderator
 
Posts: 7634
Joined: Wed Apr 06, 2005 11:18 pm
Location: Midlands, UK

RE: Klik

Postby Rhakios » Mon Sep 19, 2005 8:17 pm

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 :roll:
Bye, Rhakios
User avatar
Rhakios
Moderator
 
Posts: 7634
Joined: Wed Apr 06, 2005 11:18 pm
Location: Midlands, UK

RE: Klik

Postby Nigel » Mon Sep 19, 2005 9: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...
User avatar
Nigel
LXF regular
 
Posts: 1141
Joined: Fri Apr 08, 2005 8:03 pm
Location: Gloucestershire, UK

RE: Klik

Postby Rhakios » Mon Sep 19, 2005 9: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.
Bye, Rhakios
User avatar
Rhakios
Moderator
 
Posts: 7634
Joined: Wed Apr 06, 2005 11:18 pm
Location: Midlands, UK

Re: RE: Klik

Postby M-Saunders » Tue Sep 20, 2005 9: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
User avatar
M-Saunders
LXF regular
 
Posts: 2893
Joined: Mon Apr 11, 2005 12:14 pm


Return to Discussion

Who is online

Users browsing this forum: Yahoo [Bot] and 1 guest