Talk:SLICK

From openSUSE

Very good idea.

problems I see: many (too many) packages add fantastic dependencies (vi asks for perl...) like the Microsoft mouse asks for Internet explorer 6 :-((((

so at the first package installed from the net the SLICK will become fat :-((

for this reason, I was unable to install a console only server with a 8.0 SuSE. Any change asked for installing kde. It was so boring going through the dependency tree saying "no" that finally I accepted them...

then You will ned "reconfigured" packages, or at least "reconfigured" yast. Yast should be instructed to _NOT_ ask for dependencies not mandatorie or even if said mandatory refused once by the user. that is an other menu in the dependency tree: don't install and do not ask anymore... jdd

That is a good point. However, steps can be taken to alleviate this issue somewhat. Some of it disappears with autopackage, parts of it with static compilation, care can be taken to build packages in a way so that they don't require unusual dependancies for basic installation, whereas for additional functionality additional packages are installed etc. --Madmatt04 04:16, 29 Aug 2005 (MDT)

Is is not as easy as forcing yast to ignore dependencies. This will certainly break things heavily. Programs need other libraries or programs to actually function. The only way to get around it is to recompile a lot of rpm's by specifically excluding certain dependencies and that way within a chroot (using y2pmbuild for instance or the suse internal autobuild) the program's ./configure stage won't find those programs libraries and then also not be dependent. By doing so you basically end up with very slick packages, but you completely break compatibility with SUSE and basically become your own distro.

The slick approach is the one I chose for Yoper, where I started V2 from scratch by creating 1200 rpm spec files that had only a miniumum amount of dependencies. V1 was actually based on tgz and LFS, which made it very slick.

But again. This has then nothing to do with SUSE and you basically will not be able to ever be compatible with SUSE that way.

All in all not that easy to get around. If you find a way you just solved the key to making any distro interoperational. Andreas

Anything like the Gentoo's "USE" variable? distros could be interop at source level :-) jdd

Why not use "Compressed Application Images", where every application and all its depencencies that are not part of the base system are stored inside one single file? When you want to run the application, you click on the file, it gets loop-mounted, and the application is run.

(moved to SUPER_KLIK page)

This is certainly an interesting concept. However, I have a few questions/observations after reading the website and trying out a package of my own.

1. How portable is this? What I mean is, behind the scenes, is there a need to maintain packages for different distributions and exposing the right one to the user based on his distribution/version or is it really just one package necessary for all (supported) distros?

• klik builds the cmg files specific for each distribution, so far only debian-based distributions have been supported, and klik uses serverside-apt and the debian repository in the background. However, most cmg files can be adjusted to run on SUSE quite easily.

2. Have there been any benchmarks of how fast loading of a klik program is, since it has to be mounted etc.? Is there a noticable delay? I did not seem to experience a delay when running a klik xmule, but that is a small program and I haven't tested anything big, like OpenOffice.

• No noticeable difference to me. Perhaps you can measure it, but you won't feel it.

3. Does it work from the command line? How? What is the state of Gnome support? Is it possible to run it under other window management systems like Enlightenment etc.?

• Launching apps from the command line goes like this: ~/.zAppRun ~/Desktop/nano.cmg nano
• GNOME support is there (almost complete)
• You can even run klik from a terminal: ~/.klik nano

4. Typing a klik:// URL into KDE's Run box did not work for me, although it worked fine from Firefox.

• It should work! (It does for me)

5. I noticed slightly unintuitive behaviour: when I reclicked on the klik://xmule link in Firefox, it started to download again, eventhough I already had the application on my Desktop! I think a much better idea would be not to download the whole thing again, but to check if I already have it and then launch it. Advanced implementation of this system could also check if the remote (website) version of the klik is higher and pop up a dialog to update.

• Clicking on ~/Desktop/xmule.cmg opens the installed xmule, whereas clicking the klik://xmule link re-downloads it.

All in all, I like this system a lot, possibly better than autopackage right now, however there are some glitches that need to be ironed out or at least more clearly defined IMO. I am, however, looking forward to seeing how it works within the experimental SUPER_KLIK project. --Madmatt04 06:22, 6 Sep 2005 (MDT)

I think that the last thing openSUSE needs is duplication. As such I have changed the focus of the SUPER project and retitled SLICK to be a part of that project and vice versa. I think that with the lack of developers the last thing we need is 2 projects that do the same.

I hope this is OK .....

Andreas

Slick is it, it has package management like debian and debian like distro's. I installed slick on my hp laptop (hp pavilion ze 4417) no bug no truble, should it be some negatives it take some time to boot up. 00700

Weird situation �!

Trying to install clamav with kynaptic. Don't work, seems to work, but it doesn't. You see the package downloading and finalize without any errors, but when you try to use it... There is no package :( Very weird. This happens with more packages, a lot of. Slick release: 20051116 Some ideas ??