[prev in list] [next in list] [prev in thread] [next in thread] 

List:       klik-devel
Subject:    Re: [klik-devel] fuseiso patched to support chroot jail
From:       "Alexey Eremenko" <al4321 () gmail ! com>
Date:       2006-12-27 16:56:49
Message-ID: 7fac565a0612270856j62697c10x80efa09c8bc355c0 () mail ! gmail ! com
[Download RAW message or body]

Hello Lionel and klikers !

Now there is a new problem - compatibility across Linuxes.

Until now klik-client used bash-technology, so we stayed more-or-less
compatible across distros. That means we didn't need to compile stuff
and single client worked across many distros.

Now if we adopt the new fuse technology, how we will be able to
install a klik client ?

The standards OSes don't provide that functionality (even newest
openSUSE 10.2 boxed version doesn't) !

make a klik-client distro-specific or what ?

I can try to make a klik-client to be openSUSE 10.2 specific, but how
do we cover installation on all other distros?

Possible solution:
1. "fork" the client to "fuseklik-client" which will be distro specific.
NOTE: forking the client does NOT mean forking the project.

Rather, I see this option as to go forward and stay compatible at
once. Because that move (i.e. compiling and depending) is risky.

2. I want this new solution (fuse-klik), the other alternative (plash)
and the old solution (normal klik-client) to be compatible at both
server level (klik://myapp) *and* image-level -- final .cmg's or
.app's.

3. This way we will be able to both stay compatible on all distros,
*and* move forward not into one, but two directions simultaneously.

4. How to implement my crazy idea?

A. make the klik server generate ".cmg's" that include all that new information.
B. modify the new experimental clients to support the standard images
(I don't know if it's possible to add the generic mounting info into
the clients instead of the cmg.
C. if the above is not possible, we should sit together and define a
new image format that will be able to run across different clients.
(i.e. new format must contain generic data as well as specific data
for all 3 clients - normal, plash and fuse)

5. I know that the conservatives will hate me for that, but the
Open-Minded will love me for that idea. Basically my idea ensures
progress, while not risking with anything.
We don't risk losing Lionel. We don't risk broke compatibility with
older distros. No risk at all.

What do klikers think of it? Any ideas?

-Alexey Eremenko. 27.12.2006.
_______________________________________________
klik-devel mailing list
klik-devel@kde.org
https://mail.kde.org/mailman/listinfo/klik-devel
[prev in list] [next in list] [prev in thread] [next in thread]