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

List:       klik-devel
Subject:    [klik-devel] [klikclient commit] r847 - wiki
From:       codesite-noreply () google ! com
Date:       2008-01-20 0:00:08
Message-ID: 00163646c77404441c0f095a8b8a993 () google ! com
[Download RAW message or body]

Author: niallw
Date: Sat Jan 19 15:59:41 2008
New Revision: 847

Modified:
   wiki/deb.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/deb.wiki
==============================================================================
--- wiki/deb.wiki	(original)
+++ wiki/deb.wiki	Sat Jan 19 15:59:41 2008
@@ -48,6 +48,8 @@

 Nothing has been rebuilt using pbuilder yet!

+klikclient depends on libstdc++5!   As this is in lsb-cxx and only 
needed to run fetched programs and not for klik itself leave it to the 
lsb recommends.
+
 = Questions =

  Where and how should we split packages if at all?   Should we be 
combining these into one klik package?
@@ -82,4 +84,16 @@
    inside install/ things should have the same structure as usr/ 
normally has
   e.g., install/lib, install/share, install/lib etc.

-  i've suggested that to KillerKiwi2005 and he's ok with it, someone 
just needs to do this and change the install.py accordingly. this will 
hopefully make it much smaller and cleaner
\ No newline at end of file
+  i've suggested that to KillerKiwi2005 and he's ok with it, someone 
just needs to do this and change the install.py accordingly. this will 
hopefully make it much smaller and cleaner
+
+klikclient depends on rpm!   It should leave it to lsb to drag it in?
+
+  probono:  rpm is needed by klik itself, not for the apps installed 
with klik. so probably consistent with our logic, we'd have to keep it. 
but to be honest, i don't like it as a requirement. ideally we would 
find a python-only solution for unpacking rpms
+
+debconf must die?   kill the debconf fuse stuff and instead slap the 
user in the face with a message if they try and run klik without fuse rights!
+
+  probono:  debconf: i'd really prefer to have it as it is now
+
+Should we be depending on anything like a browser?   I would say no, 
recommending is fine.   Wouldn't/couldn't a klik'd browser support 
klik'ing new apps?
+
+  probono:  klik works well on the CLI ... so no browser
\ No newline at end of file
_______________________________________________
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]