[prev in list] [next in list] [prev in thread] [next in thread]
List: klik-devel
Subject: Re: [klik-devel] klik-devel Digest, Vol 16, Issue 4
From: "Jason Taylor" <killerkiwi2005 () gmail ! com>
Date: 2007-05-25 8:03:59
Message-ID: 94dd8f6f0705250103n191e77bfgf32e3c84d9772a75 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi All
Been out of the loop for a while (new baby)... so probably will be for a
while longer :)
In regards to the ROX format i'm for reusing all we can, but striping out
anything that is duplicated in the desktop file (following the
freedesktop.org spec) (ie multilingual description). Add the minimum extra
that we need.
The reason for the multiple icon paths is so we could have different icons
sizes. There may be a better way to do this more like what gtk/gnome does
using different paths.
The "real" (as in goals) difference between 0install and klik2 I think is
dependency sharing as the klik philosophy is 1 app = 1 file.
Not much more to add other than has anybody heard from Probono lately I
notice nothing from him on the list, and the wiki is full of span that he
was cleaning up....
Killerkiwi
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
> *****************************************
>
[Attachment #5 (text/html)]
Hi All<br><br>Been out of the loop for a while (new baby)... so probably \
will be for a while longer :)<br><br>In regards to the ROX format i'm \
for reusing all we can, but striping out anything that is duplicated in the \
desktop file (following the <a \
href="http://freedesktop.org">freedesktop.org</a> spec) (ie multilingual \
description). Add the minimum extra that we need.<br><br>The reason for the \
multiple icon paths is so we could have different icons sizes. There \
may be a better way to do this more like what gtk/gnome does \
using different paths. <br><br>The "real" (as in goals) \
difference between 0install and klik2 I think is dependency sharing as the \
klik philosophy is 1 app = 1 file. <br><br>Not much more to add other \
than has anybody heard from Probono lately I notice nothing from him on the \
list, and the wiki is full of span that he was cleaning up.... \
<br><br>Killerkiwi<br><br><br><div><span class="gmail_quote">On 5/24/07, <b \
class="gmail_sendername"><a \
href="mailto:klik-devel-request@kde.org">klik-devel-request@kde.org</a></b> \
<<a href="mailto:klik-devel-request@kde.org"> \
klik-devel-request@kde.org</a>> wrote:</span><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Send klik-devel mailing list \
submissions to<br> <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br><br>To subscribe \
or unsubscribe via the World Wide Web, \
visit<br> <a \
href="https://mail.kde.org/mailman/listinfo/klik-devel">https://mail.kde.org/mailman/listinfo/klik-devel
</a><br>or, via email, send a message with subject or body 'help' \
to<br> <a \
href="mailto:klik-devel-request@kde.org">klik-devel-request@kde.org</a><br><br>You \
can reach the person managing the list \
at<br> <a \
href="mailto:klik-devel-owner@kde.org">klik-devel-owner@kde.org</a><br><br>When \
replying, please edit your Subject line so it is more specific<br>than \
"Re: Contents of klik-devel digest..."<br><br><br>Today's \
Topics: <br><br> 1. Re: klik-devel Digest, Vol 15, Issue 8 \
(Thomas Leonard)<br> 2. Re: klik-devel Digest, Vol 15, Issue 1 \
(Thomas Leonard)<br> 3. Re: klik-devel Digest, Vol 15, Issue 8 \
(<a href="mailto:lionel.tricon@free.fr"> \
lionel.tricon@free.fr</a>)<br> 4. Re: klik-devel Digest, Vol \
15, Issue 1 (<a href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a>)<br> \
5. Re: klik-devel Digest, Vol 15, Issue 1 (Thomas Leonard)<br> \
6. Re: klik-devel Digest, Vol 15, Issue 1 (Lionel Tricon (perso)) \
<br><br><br>----------------------------------------------------------------------<br><br>Message: \
1<br>Date: Wed, 23 May 2007 19:10:22 +0100<br>From: Thomas Leonard <<a \
href="mailto:talex5@gmail.com">talex5@gmail.com</a> ><br>Subject: Re: \
[klik-devel] klik-devel Digest, Vol 15, Issue 8<br>To: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br>Message-ID: \
<<a href="mailto:4654838E.7050907@gmail.com">4654838E.7050907@gmail.com \
</a>><br>Content-Type: text/plain; charset=ISO-8859-1<br><br>Lionel \
Tricon wrote:<br>> > Ok, the following is an attempt to merge the rox \
file format with all needed<br>> > information to run the binary from \
the cmg file (to be honest, with some <br>> > rework of the original \
format ...).<br><br>Why change it at all? Extra elements can be added \
easily, and there's no<br>point renaming existing elements just for the \
sake of it. e.g. (starting<br>at the top of your example): <br><br>- You \
don't really need the maintainer name because it's in the \
signature.<br>- You don't need the encoding, because it's in the \
XML declaration.<br>- You don't need the version on the name, because \
it comes later on the <br> <implementation>.<br>- I \
don't see the point in redefining <category>. Putting English \
text<br> in it just means more translation work.<br>- You \
don't need <license> because it comes later already. <br>- \
<desktop> is OK, but it should be a relative path inside the \
download<br> (and it should be an attribute of the \
implementation, because it might<br> move between versions)<br>- \
Why change <icon>'s href from a URL to a local path? \
<br> - Adding a size attribute is fine, though.<br>- Grouping \
<icon> inside <icons> isn't unreasonable, but it breaks \
the<br> existing format for no good reason (same for some other \
places).<br>- You don't need <implementations> because \
there's already <group> <br>- You don't need \
'required' because there's already a <requires> \
element<br>- You don't need <post>; it already exists as \
<recipe><br>- <action> may be useful.<br>- You don't need \
<runtime> because it already exists as 'main' <br>- You \
don't need <env> because <environment> already \
exists.<br> - The 'mode' attribute is useful, \
though.<br><br>>> >> YES. we should use the ROX format... main \
advantage is the tools that <br>>> >> already exist that we can \
borrow from zero-install with 90% of the work is<br>>> >> \
already done<br><br>Note that Zero Install is not part of ROX, although ROX \
happens to use it.<br><br><br>
--<br>Dr Thomas Leonard \
<a href="http://rox.sourceforge.net">http://rox.sourceforge.net</a><br>GPG: \
9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 \
3CC1<br><br><br>------------------------------<br><br>Message: 2 <br>Date: \
Wed, 23 May 2007 19:31:50 +0100<br>From: Thomas Leonard <<a \
href="mailto:talex5@gmail.com">talex5@gmail.com</a>><br>Subject: Re: \
[klik-devel] klik-devel Digest, Vol 15, Issue 1<br>To: <a \
href="mailto:klik-devel@kde.org"> klik-devel@kde.org</a><br>Message-ID: \
<<a href="mailto:46548896.6000303@gmail.com">46548896.6000303@gmail.com</a>><br>Content-Type: \
text/plain; charset=ISO-8859-1<br><br>lionel.tricon at <a \
href="http://free.fr">free.fr </a> wrote:<br>> Selon Jason Taylor \
<killerkiwi2005 at <a \
href="http://gmail.com">gmail.com</a>>:<br>>> More random \
thoughts... should we approach the guy(s?) who wrote zero<br>>> \
install about merging the 2 techniques... really what we are doing is \
<br>>> creating zero install into a single file and making it \
executable... the<br>>> projects seem (to me any way) very similar at \
this point.<br>><br>> I never used zeroinstall but in my \
understanding the software need to be modify <br>> to support \
0install<br><br>Software such as Firefox, Blender, Inkscape etc doesn't \
need to be<br>modified. Programs which uses hard-coded paths do \
(there's no<br>"intellipatch" step like with Klik). \
<br><br>> and it seems that it needs a kernel module (lazyfs) \
?<br><br>lazyfs hasn't been used since 2005. No kernel patching (or \
even root<br>access) is needed.<br><br>> Except the xml file description \
which seems interresting to reuse, it's not <br>> obvious for me \
that that kind of software brings something new to the klik<br>> \
model.<br><br>There's a list of differences on the \
site:<br><br> <a \
href="http://0install.net/links.html">http://0install.net/links.html \
</a><br><br>> If someone can explain me how it works, it would be great \
because the website is<br>> not very clear ...<br><br>Well, it works a \
lot like Klik really ;-) Probably easiest just to try<br>it though. If \
you're on Ubuntu (feisty), type: <br><br> $ sudo apt-get \
install zeroinstall-injector<br><br>(or use 'yum' on Fedora, etc. \
If your distro doesn't include it yet,<br>packages are at <a \
href="http://0install.net/injector.html">http://0install.net/injector.html \
</a>)<br><br>Then run something, e.g.:<br><br> $ 0launch <a \
href="http://rox.sourceforge.net/2005/interfaces/ROX-Filer">http://rox.sourceforge.net/2005/interfaces/ROX-Filer</a><br><br><br>--<br>Dr \
Thomas Leonard \
<a href="http://rox.sourceforge.net">http://rox.sourceforge.net</a><br>GPG: \
9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 \
3CC1<br><br><br>------------------------------<br><br>Message: 3<br>Date: \
Wed, 23 May 2007 23:09:11 +0200 <br>From: <a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a><br>Subject: \
Re: [klik-devel] klik-devel Digest, Vol 15, Issue 8<br>To: Thomas Leonard \
<<a href="mailto:talex5@gmail.com">talex5@gmail.com</a>> <br>Cc: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br>Message-ID: \
<<a href="mailto:1179954551.4654ad77a32cf@imp.free.fr">1179954551.4654ad77a32cf@imp.free.fr</a>><br>Content-Type: \
text/plain; charset=ISO-8859-1 <br><br>Hi Thomas,<br><br>I read your email \
with a lot of interrest. Thank you for your detailed comments.<br>To be \
honest, i agree with a lot of them :-) Especially for those about \
renaming<br>existing elements ...<br><br> But keep in mind that in the \
klik2 model, the application is virtually installed<br>into the filesystem. \
Even if my changes were not really useful, it was just a<br>proposal and it \
was not in my intention to deeply change the rox file format. <br><br>In \
the klik2 model, you need :<br>- to know how to run the application : \
that's the raison of the <runtime> area<br>- to display an icon \
when the cmg file is located on the desktop or wherever you<br>want : \
that's why i put a local path since it gives the location of the icon \
<br>into the cmg file (a way to extract it)<br>- to give the path of the \
.desktop file (we can imagine a situation where you<br>can installed the \
cmg file onto the disk). It's not mandatory but it's just \
an<br>idea <br>- to display meta-data (for example, the summary of the \
application) in<br>different languages<br>- to know how to build the cmg \
file (list of packages, actions to apply just<br>before building the cmg \
file) : that's the raison of the <action> tags <br><br>If the rox \
file format can be slightly modified to propose all these<br>informations \
(except if i am totally wrong, some of them were missing), i will<br>be \
very happy. My first intention was to brainstorm about the cmg file format \
<br>and propose some enhancements.<br><br>I am not an fundamentalist and my \
concern is only to dispose of a rox file<br>format that can fit our need in \
a near future.<br><br>Lionel<br><br><br>------------------------------ \
<br><br>Message: 4<br>Date: Wed, 23 May 2007 23:26:36 +0200<br>From: <a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a><br>Subject: \
Re: [klik-devel] klik-devel Digest, Vol 15, Issue 1<br>To: Thomas Leonard \
< <a href="mailto:talex5@gmail.com">talex5@gmail.com</a>><br>Cc: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br>Message-ID: \
<<a href="mailto:1179955596.4654b18caf00c@imp.free.fr">1179955596.4654b18caf00c@imp.free.fr
</a>><br>Content-Type: text/plain; charset=ISO-8859-1<br><br>Selon \
Thomas Leonard <<a \
href="mailto:talex5@gmail.com">talex5@gmail.com</a>>:<br>> Software \
such as Firefox, Blender, Inkscape etc doesn't need to be <br>> \
modified. Programs which uses hard-coded paths do (there's no<br>> \
"intellipatch" step like with Klik).<br><br>Klik2 (well, next \
version of klik) doesn't need to change absolute path. For the \
<br>current version of klik, you have to.<br><br>> lazyfs hasn't \
been used since 2005. No kernel patching (or even root<br>> access) is \
needed.<br><br>ok<br><br>> Well, it works a lot like Klik really ;-)<br> \
<br>My impression is that 0install is close to the current klik \
implementation.<br><br>Klik2 will add some major improvements :<br>- union \
mounting : virtualize the application into the filesystem (only from \
the<br>application point of view) <br>- sand boxing feature : allows you to \
test an application without changing the<br>local filesystem or put the \
modifications into a directory or a file (loopback<br>mounting)<br>- no \
need to modify absolute paths : the application is unmodified <br><br>But i \
agree that 0install propose some interesting features (security, \
dynamic<br>linking, ...). And klik2 could be almost plateforme independent \
if you consider<br>that fuse is available as well on *bsd, mac, ... \
it's not perfect, but it's <br>better than nothing \
:-)<br><br>Lionel<br><br><br>------------------------------<br><br>Message: \
5<br>Date: Wed, 23 May 2007 22:59:08 +0100<br>From: "Thomas \
Leonard" <<a href="mailto:talex5@gmail.com">talex5@gmail.com \
</a>><br>Subject: Re: [klik-devel] klik-devel Digest, Vol 15, Issue \
1<br>To: <a href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br>Message-ID:<br> <<a \
href="mailto:cd53a0140705231459u63f4411bu380dd28bbe47d778@mail.gmail.com"> \
cd53a0140705231459u63f4411bu380dd28bbe47d778@mail.gmail.com</a>><br>Content-Type: \
text/plain; charset=ISO-8859-1; format=flowed<br><br>On 5/23/07, <a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a> <<a \
href="mailto:lionel.tricon@free.fr"> lionel.tricon@free.fr</a>> \
wrote:<br>> My impression is that 0install is close to the current klik \
implementation.<br>><br>> Klik2 will add some major improvements \
:<br>> - union mounting : virtualize the application into the filesystem \
(only from the <br>> application point of view)<br><br>Sounds good... \
but can we separate this from the installation \
system?<br><br>e.g.:<br><br>- We have a package ('abiword')<br>- It \
depends on another package ('klik-union-fs') <br><br>Now, when I \
do:<br><br>$ 0launch http://.../abiword.xml<br><br>Abiword runs in a new \
namespace (provided by klik-union-fs). Just as<br>Python programs need a \
Python interpreter to run, Abiword needs the<br>Klik union system (though \
actually Abiword doesn't need it because <br>it's relocatable; it \
already works through normal Zero Install).<br><br>> - sand boxing \
feature : allows you to test an application without changing the<br>> \
local filesystem or put the modifications into a directory or a file \
(loopback <br>> mounting)<br>> - no need to modify absolute paths : \
the application is unmodified<br><br>Again, that sounds useful, but \
possibly for other programs too (e.g.<br>programs installed using apt-get). \
Will you be supporting multiple <br>'profiles' per program? \
e.g.<br><br>$ klik-create-profile abifoo http://.../abiword.xml<br>$ \
klik-create-profile abibar http://.../abiword.xml<br>$ abifoo<br>$ \
abibar<br><br>(where changes made in abifoo don't affect abibar). \
<br><br>> But i agree that 0install propose some interesting features \
(security, dynamic<br>> linking, ...). And klik2 could be almost \
plateforme independent if you consider<br>> that fuse is available as \
well on *bsd, mac, ... it's not perfect, but it's <br>> better \
than nothing :-)<br><br><br>--<br>Dr Thomas \
Leonard \
<a href="http://rox.sourceforge.net">http://rox.sourceforge.net</a><br>GPG: \
9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 \
3CC1<br><br><br>------------------------------ <br><br>Message: 6<br>Date: \
Thu, 24 May 2007 10:02:09 +0200<br>From: "Lionel Tricon (perso)" \
<<a href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a>><br>Subject: \
Re: [klik-devel] klik-devel Digest, Vol 15, Issue 1 <br>To: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br>Message-ID: \
<<a href="mailto:46554681.7060706@free.fr">46554681.7060706@free.fr</a>><br>Content-Type: \
text/plain; charset=ISO-8859-1<br><br>Thomas Leonard a ?crit : <br>> \
Sounds good... but can we separate this from the installation \
system?<br>><br>Not sure i understand what you mean by "separate \
this from the<br>installation system". In fact there are several \
virtualization solution <br>for klik2 available and my solution (fuse based \
only) is one of them<br>(maybe not the best one but the only workable for \
the moment). In<br>details, i patched fuseiso and fusecramfs to merge to \
real filesystem<br>with the filesystem located into an iso or cramfs file. \
When i mount <br>such a filesystem on a directory (for example \
/tmp/app/1/mnt), i use a<br>fake chroot (based on the LD_PRELOAD feature) \
to put the merged<br>filesystem into a jail. The application run into the \
virtual namespace<br>whereas the application files are not really installed \
on disk. <br><br>The example below show you quickly how it works to execute \
an<br>application located into a cmg file :<br><br># mkdir -p \
/tmp/app/1/mnt<br># ln -s ~path/fichier.cmg /tmp/app/1/image<br># \
/opt/klikutils/bin/fuse[iso|cram] -n -u /opt/klikutils <br>/tmp/app/1/image \
/tmp/app/1/mnt<br># export KLIK_BASENAME=/opt/klikutils<br># export \
FAKECHROOT_EXCLUDE_PATHS=/tmp:/proc:/dev:/var/run<br># export \
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${KLIK_BASENAME}/lib/fakechroot<br># \
export LD_PRELOAD=$LD_PRELOAD: libfakechroot.so<br># \
${KLIK_BASENAME}/bin/chroot /tmp/app/1/mnt<br><run the \
application><br># exit<br># /opt/klikutils/bin/fusermount -u \
/tmp/app/1/mnt<br># rm -f /tmp/app/1/image<br># rmdir /tmp/app/1/mnt/<br># \
rmdir /tmp/app/1 <br><br>And remember that in the klik model, 1 app == 1 \
file. A cmg package<br>cannot depends of an another cmg package. Each one \
run in its own namespace.<br><br>With all of that, you do not need to \
relocate the application al all. <br>> Again, that sounds useful, but \
possibly for other programs too (e.g.<br>> programs installed using \
apt-get). Will you be supporting multiple<br>> 'profiles' per \
program? e.g.<br>><br>When you run fuseiso or fusecram, you can redirect \
the modification into <br>a directory. It works for the application located \
into the cmg file as<br>well for all applications available on disk (there \
are no difference<br>between both, you run what you want, real application \
or virtualized<br> application ; you can fuse mount an empty cmg file and \
launch a real<br>application without any troubles). To be accurate, only \
the $HOME of the<br>user is concerne (it's by design and can be changed \
easily). I consider <br>that a normal user will only modify it's \
private directory, not other<br>part of the root filesystem.<br><br>So, you \
can put modifications into an usb key or into a file mounted in<br>loopback \
(we can use mountlo which is fuse-based for that). <br><br>Again, i \
don't know exactly what you mean by "multiples profiles" but \
i<br>guess that yes since you can redirect each time data in a new \
location.<br>For the moment, the backend is ready but nothing is done to \
integrate it <br>for the end user ; the engine is ready but not the \
frontend !<br><br>Just an example. The following make a union between the \
root directory<br>and the filesystem present into the test.cmg file (the \
new directory<br>will be available into the /tmp/app/1/mnt filesystem). The \
-b option <br>redirect writes from the $HOME user into the /tmp/test \
directory.<br><br>You have just to put the /tmp/app/1/mnt directory into a \
jail from the<br>application point of view and you can run it (since fuse \
do not support <br>by design special files and suid bits, we exclude from \
the jail some<br>directories like /tmp, /proc, /dev and /var/run to allow \
direct access<br>on them).<br><br># /opt/klikutils/bin/fuseiso -n -u \
/opt/klikutils -b /tmp/test <br>/home/lionel/Desktop/test.cmg \
/tmp/app/1/mnt<br><br>That's how it \
works,<br>Lionel<br><br><br>------------------------------<br><br>_______________________________________________<br>klik-devel \
mailing list<br><a href="mailto:klik-devel@kde.org"> \
<br></blockquote></div><br>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic