[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"> klik-devel@kde.org</a><br><a \
href="https://mail.kde.org/mailman/listinfo/klik-devel">https://mail.kde.org/mailman/listinfo/klik-devel</a><br><br><br>End \
of klik-devel Digest, Vol 16, Issue 4<br>***************************************** \
<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