On 5/24/07, klik-devel-request@kde.org < klik-devel-request@kde.org> wrote:

Send klik-devel mailing list submissions to
        klik-devel@kde.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://mail.kde.org/mailman/listinfo/klik-devel
or, via email, send a message with subject or body 'help' to
        klik-devel-request@kde.org

You can reach the person managing the list at
         klik-devel-owner@kde.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of klik-devel digest..."

Today's Topics:

   1. Re: klik-devel Digest, Vol 15, Issue 8 (Thomas Leonard)
   2. Re: klik-devel Digest, Vol 15, Issue 1 (Thomas Leonard)
   3. Re: klik-devel Digest, Vol 15, Issue 8 ( lionel.tricon@free.fr)
   4. Re: klik-devel Digest, Vol 15, Issue 1 (lionel.tricon@free.fr)
   5. Re: klik-devel Digest, Vol 15, Issue 1 (Thomas Leonard)
   6. Re: klik-devel Digest, Vol 15, Issue 1 (Lionel Tricon (perso))

----------------------------------------------------------------------

Message: 1
Date: Wed, 23 May 2007 19:10:22 +0100
From: Thomas Leonard <talex5@gmail.com >
Subject: Re: [klik-devel] klik-devel Digest, Vol 15, Issue 8
To: klik-devel@kde.org
Message-ID: <4654838E.7050907@gmail.com >
Content-Type: text/plain; charset=ISO-8859-1

Lionel Tricon wrote:
> > Ok, the following is an attempt to merge the rox file format with all needed
> > information to run the binary from the cmg file (to be honest, with some
> > rework of the original format ...).

Why change it at all? Extra elements can be added easily, and there's no
point renaming existing elements just for the sake of it. e.g. (starting
at the top of your example):

- You don't really need the maintainer name because it's in the signature.
- You don't need the encoding, because it's in the XML declaration.
- You don't need the version on the name, because it comes later on the
  <implementation>.
- I don't see the point in redefining <category>. Putting English text
  in it just means more translation work.
- You don't need <license> because it comes later already.
- <desktop> is OK, but it should be a relative path inside the download
  (and it should be an attribute of the implementation, because it might
  move between versions)
- Why change <icon>'s href from a URL to a local path?
  - Adding a size attribute is fine, though.
- Grouping <icon> inside <icons> isn't unreasonable, but it breaks the
  existing format for no good reason (same for some other places).
- You don't need <implementations> because there's already <group>
- You don't need 'required' because there's already a <requires> element
- You don't need <post>; it already exists as <recipe>
- <action> may be useful.
- You don't need <runtime> because it already exists as 'main'
- You don't need <env> because <environment> already exists.
  - The 'mode' attribute is useful, though.

>> >> YES. we should use the ROX format... main advantage is the tools that
>> >> already exist that we can borrow from zero-install with 90% of the work is
>> >> already done

Note that Zero Install is not part of ROX, although ROX happens to use it.

--
Dr Thomas Leonard               http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1

------------------------------

Message: 2
Date: Wed, 23 May 2007 19:31:50 +0100
From: Thomas Leonard <talex5@gmail.com>
Subject: Re: [klik-devel] klik-devel Digest, Vol 15, Issue 1
To: klik-devel@kde.org
Message-ID: <46548896.6000303@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

lionel.tricon at free.fr wrote:
> Selon Jason Taylor <killerkiwi2005 at gmail.com>:
>> More random thoughts... should we approach the guy(s?) who wrote zero
>> install about merging the 2 techniques... really what we are doing is
>> creating zero install into a single file and making it executable... the
>> projects seem (to me any way) very similar at this point.
>
> I never used zeroinstall but in my understanding the software need to be modify
> to support 0install

Software such as Firefox, Blender, Inkscape etc doesn't need to be
modified. Programs which uses hard-coded paths do (there's no
"intellipatch" step like with Klik).

> and it seems that it needs a kernel module (lazyfs) ?

lazyfs hasn't been used since 2005. No kernel patching (or even root
access) is needed.

> Except the xml file description which seems interresting to reuse, it's not
> obvious for me that that kind of software brings something new to the klik
> model.

There's a list of differences on the site:

  http://0install.net/links.html

> If someone can explain me how it works, it would be great because the website is
> not very clear ...

Well, it works a lot like Klik really ;-) Probably easiest just to try
it though. If you're on Ubuntu (feisty), type:

  $ sudo apt-get install zeroinstall-injector

(or use 'yum' on Fedora, etc. If your distro doesn't include it yet,
packages are at http://0install.net/injector.html )

Then run something, e.g.:

  $ 0launch http://rox.sourceforge.net/2005/interfaces/ROX-Filer

--
Dr Thomas Leonard               http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1

------------------------------

Message: 3
Date: Wed, 23 May 2007 23:09:11 +0200
From: lionel.tricon@free.fr
Subject: Re: [klik-devel] klik-devel Digest, Vol 15, Issue 8
To: Thomas Leonard <talex5@gmail.com>
Cc: klik-devel@kde.org
Message-ID: <1179954551.4654ad77a32cf@imp.free.fr>
Content-Type: text/plain; charset=ISO-8859-1

Hi Thomas,

I read your email with a lot of interrest. Thank you for your detailed comments.
To be honest, i agree with a lot of them :-) Especially for those about renaming
existing elements ...

But keep in mind that in the klik2 model, the application is virtually installed
into the filesystem. Even if my changes were not really useful, it was just a
proposal and it was not in my intention to deeply change the rox file format.

In the klik2 model, you need :
- to know how to run the application : that's the raison of the <runtime> area
- to display an icon when the cmg file is located on the desktop or wherever you
want : that's why i put a local path since it gives the location of the icon
into the cmg file (a way to extract it)
- to give the path of the .desktop file (we can imagine a situation where you
can installed the cmg file onto the disk). It's not mandatory but it's just an
idea
- to display meta-data (for example, the summary of the application) in
different languages
- to know how to build the cmg file (list of packages, actions to apply just
before building the cmg file) : that's the raison of the <action> tags

If the rox file format can be slightly modified to propose all these
informations (except if i am totally wrong, some of them were missing), i will
be very happy. My first intention was to brainstorm about the cmg file format
and propose some enhancements.

I am not an fundamentalist and my concern is only to dispose of a rox file
format that can fit our need in a near future.

Lionel

------------------------------

Message: 4
Date: Wed, 23 May 2007 23:26:36 +0200
From: lionel.tricon@free.fr
Subject: Re: [klik-devel] klik-devel Digest, Vol 15, Issue 1
To: Thomas Leonard < talex5@gmail.com>
Cc: klik-devel@kde.org
Message-ID: <1179955596.4654b18caf00c@imp.free.fr >
Content-Type: text/plain; charset=ISO-8859-1

Selon Thomas Leonard <talex5@gmail.com>:
> Software such as Firefox, Blender, Inkscape etc doesn't need to be
> modified. Programs which uses hard-coded paths do (there's no
> "intellipatch" step like with Klik).

Klik2 (well, next version of klik) doesn't need to change absolute path. For the
current version of klik, you have to.

> lazyfs hasn't been used since 2005. No kernel patching (or even root
> access) is needed.

ok

> Well, it works a lot like Klik really ;-)

My impression is that 0install is close to the current klik implementation.

Klik2 will add some major improvements :
- union mounting : virtualize the application into the filesystem (only from the
application point of view)
- sand boxing feature : allows you to test an application without changing the
local filesystem or put the modifications into a directory or a file (loopback
mounting)
- no need to modify absolute paths : the application is unmodified

But i agree that 0install propose some interesting features (security, dynamic
linking, ...). And klik2 could be almost plateforme independent if you consider
that fuse is available as well on *bsd, mac, ... it's not perfect, but it's
better than nothing :-)

Lionel

------------------------------

Message: 5
Date: Wed, 23 May 2007 22:59:08 +0100
From: "Thomas Leonard" <talex5@gmail.com >
Subject: Re: [klik-devel] klik-devel Digest, Vol 15, Issue 1
To: klik-devel@kde.org
Message-ID:
        < cd53a0140705231459u63f4411bu380dd28bbe47d778@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 5/23/07, lionel.tricon@free.fr < lionel.tricon@free.fr> wrote:
> My impression is that 0install is close to the current klik implementation.
>
> Klik2 will add some major improvements :
> - union mounting : virtualize the application into the filesystem (only from the
> application point of view)

Sounds good... but can we separate this from the installation system?

e.g.:

- We have a package ('abiword')
- It depends on another package ('klik-union-fs')

Now, when I do:

$ 0launch http://.../abiword.xml

Abiword runs in a new namespace (provided by klik-union-fs). Just as
Python programs need a Python interpreter to run, Abiword needs the
Klik union system (though actually Abiword doesn't need it because
it's relocatable; it already works through normal Zero Install).

> - sand boxing feature : allows you to test an application without changing the
> local filesystem or put the modifications into a directory or a file (loopback
> mounting)
> - no need to modify absolute paths : the application is unmodified

Again, that sounds useful, but possibly for other programs too (e.g.
programs installed using apt-get). Will you be supporting multiple
'profiles' per program? e.g.

$ klik-create-profile abifoo http://.../abiword.xml
$ klik-create-profile abibar http://.../abiword.xml
$ abifoo
$ abibar

(where changes made in abifoo don't affect abibar).

> But i agree that 0install propose some interesting features (security, dynamic
> linking, ...). And klik2 could be almost plateforme independent if you consider
> that fuse is available as well on *bsd, mac, ... it's not perfect, but it's
> better than nothing :-)

--
Dr Thomas Leonard               http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1

------------------------------

Message: 6
Date: Thu, 24 May 2007 10:02:09 +0200
From: "Lionel Tricon (perso)" <lionel.tricon@free.fr>
Subject: Re: [klik-devel] klik-devel Digest, Vol 15, Issue 1
To: klik-devel@kde.org
Message-ID: <46554681.7060706@free.fr>
Content-Type: text/plain; charset=ISO-8859-1

Thomas Leonard a ?crit :
> Sounds good... but can we separate this from the installation system?
>
Not sure i understand what you mean by "separate this from the
installation system". In fact there are several virtualization solution
for klik2 available and my solution (fuse based only) is one of them
(maybe not the best one but the only workable for the moment). In
details, i patched fuseiso and fusecramfs to merge to real filesystem
with the filesystem located into an iso or cramfs file. When i mount
such a filesystem on a directory (for example /tmp/app/1/mnt), i use a
fake chroot (based on the LD_PRELOAD feature) to put the merged
filesystem into a jail. The application run into the virtual namespace
whereas the application files are not really installed on disk.

The example below show you quickly how it works to execute an
application located into a cmg file :

# mkdir -p /tmp/app/1/mnt
# ln -s ~path/fichier.cmg /tmp/app/1/image
# /opt/klikutils/bin/fuse[iso|cram] -n -u /opt/klikutils
/tmp/app/1/image /tmp/app/1/mnt
# export KLIK_BASENAME=/opt/klikutils
# export FAKECHROOT_EXCLUDE_PATHS=/tmp:/proc:/dev:/var/run
# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${KLIK_BASENAME}/lib/fakechroot
# export LD_PRELOAD=$LD_PRELOAD: libfakechroot.so
# ${KLIK_BASENAME}/bin/chroot /tmp/app/1/mnt
<run the application>
# exit
# /opt/klikutils/bin/fusermount -u /tmp/app/1/mnt
# rm -f /tmp/app/1/image
# rmdir /tmp/app/1/mnt/
# rmdir /tmp/app/1

And remember that in the klik model, 1 app == 1 file. A cmg package
cannot depends of an another cmg package. Each one run in its own namespace.

With all of that, you do not need to relocate the application al all.
> Again, that sounds useful, but possibly for other programs too (e.g.
> programs installed using apt-get). Will you be supporting multiple
> 'profiles' per program? e.g.
>
When you run fuseiso or fusecram, you can redirect the modification into
a directory. It works for the application located into the cmg file as
well for all applications available on disk (there are no difference
between both, you run what you want, real application or virtualized
application ; you can fuse mount an empty cmg file and launch a real
application without any troubles). To be accurate, only the $HOME of the
user is concerne (it's by design and can be changed easily). I consider
that a normal user will only modify it's private directory, not other
part of the root filesystem.

So, you can put modifications into an usb key or into a file mounted in
loopback (we can use mountlo which is fuse-based for that).

Again, i don't know exactly what you mean by "multiples profiles" but i
guess that yes since you can redirect each time data in a new location.
For the moment, the backend is ready but nothing is done to integrate it
for the end user ; the engine is ready but not the frontend !

Just an example. The following make a union between the root directory
and the filesystem present into the test.cmg file (the new directory
will be available into the /tmp/app/1/mnt filesystem). The -b option
redirect writes from the $HOME user into the /tmp/test directory.

You have just to put the /tmp/app/1/mnt directory into a jail from the
application point of view and you can run it (since fuse do not support
by design special files and suid bits, we exclude from the jail some
directories like /tmp, /proc, /dev and /var/run to allow direct access
on them).

# /opt/klikutils/bin/fuseiso -n -u /opt/klikutils -b /tmp/test
/home/lionel/Desktop/test.cmg /tmp/app/1/mnt

That's how it works,
Lionel

------------------------------

_______________________________________________
klik-devel mailing list
klik-devel@kde.org
https://mail.kde.org/mailman/listinfo/klik-devel

End of klik-devel Digest, Vol 16, Issue 4
*****************************************