Active Topics
-
Porting apps to Leste (32)
to Maemo 7 / Leste by Arno_11 - 4 days, 23 hrs ago -
[ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900 (2,264)
to Maemo 5 / Fremantle by panjgoori - 6 days, 17 hrs ago - more...
| The Following User Says Thank You to mikkov For This Useful Post: | ||
 |
|
2009-12-20
, 17:41
|
|
Posts: 1,635 |
Thanked: 1,816 times |
Joined on Apr 2008
@ Manchester, England
|
#12
|
ok javis, that sounds more like I'm thinking 
its certainly not uglier in my eyes, it just allows everything else to work as is
i dont like the spray around file system that the optification tools give and no knowledge over what goes where.
it would of course have to handle the case the /usr/share/liqbase folder exists and move it though, which becomes amusing
its certainly not uglier in my eyes, it just allows everything else to work as is
i dont like the spray around file system that the optification tools give and no knowledge over what goes where.
it would of course have to handle the case the /usr/share/liqbase folder exists and move it though, which becomes amusing
__________________
liqbase sketching the future.
like what i say? hit the Thanks, thanks!
twitter.com/lcuk
liqbase sketching the future.
like what i say? hit the Thanks, thanks!
twitter.com/lcuk
|
|
2009-12-20
, 17:42
|
|
Posts: 1,208 |
Thanked: 1,028 times |
Joined on Oct 2007
|
#13
|
Originally Posted by javispedro
and because libliqbase is already out there you have to take care that existing stuff in /usr/share/liqbase is moved to the new directory. And you would have to bump version requirement of libliqbase for all liqbase packages, to make sure that the new libliqbase is installed.
One uglier but also working option is let the preinst script create /usr/share/liqbase -> /opt/liqbase link, then let the packages unpack in /usr/share/liqbase as usual.
|
|
2009-12-20
, 17:51
|
|
Posts: 1,635 |
Thanked: 1,816 times |
Joined on Apr 2008
@ Manchester, England
|
#14
|
is there a tool which i can point at an existing directory and have it list exactly what optification would do to it?
i mean just something on the console which would first list dir tree of the sected path
then show the split of the new dirtrees showin the results
i bet using optification tool (reading the rules in the readme anyway) would result in more mess and bigger space wasting than my simpler generic approach.
i mean just something on the console which would first list dir tree of the sected path
then show the split of the new dirtrees showin the results
i bet using optification tool (reading the rules in the readme anyway) would result in more mess and bigger space wasting than my simpler generic approach.
__________________
liqbase sketching the future.
like what i say? hit the Thanks, thanks!
twitter.com/lcuk
liqbase sketching the future.
like what i say? hit the Thanks, thanks!
twitter.com/lcuk
|
|
2009-12-20
, 17:56
|
|
Posts: 1,208 |
Thanked: 1,028 times |
Joined on Oct 2007
|
#15
|
Originally Posted by lcuk
run "maemo-optify-deb your_unoptified_deb.deb" and see the file list for example with less.
is there a tool which i can point at an existing directory and have it list exactly what optification would do to it?
i mean just something on the console which would first list dir tree of the sected path
then show the split of the new dirtrees showin the results
i bet using optification tool (reading the rules in the readme anyway) would result in more mess and bigger space wasting than my simpler generic approach.
I truly am trying to save your and testers time
 |
|
2009-12-20
, 17:57
|
|
Posts: 1,070 |
Thanked: 1,604 times |
Joined on Sep 2008
@ Helsinki
|
#16
|
Originally Posted by mikkov
Well, I also don't want to see thousands of symlinks in my system pointing to /opt/..., as for the changes, I think this is very trivial and easy to change if you have good Debian rules for your apps.
Because I don't want to see packages with /opt/bin, /opt/share etc directories. And if it happens that /opt is not needed somewhere in the future, you don't have to do anything to remove optification. And it really is easier.
By the packages that I had chance to download from the OVI store seems that devs aren't using the 'lazy method', same for the latest Qt stuff, probably Nokia is advertising/pushing the 'direct' use of /opt
You can also check the -devel ML archive where the maemo-optify author suggested the "better method".
| The Following User Says Thank You to VDVsx For This Useful Post: | ||
|
|
2009-12-20
, 18:08
|
|
Posts: 36 |
Thanked: 17 times |
Joined on Dec 2009
|
#17
|
Noob question from someone who's just done his second reflash after installing too many unoptified apps :
As an end-user, If a new, optified version version of a previously un-optified app is installed, does it automatically tidy up the files that the un-optified version had created, and free up the filespace?
WS
As an end-user, If a new, optified version version of a previously un-optified app is installed, does it automatically tidy up the files that the un-optified version had created, and free up the filespace?
WS
| The Following User Says Thank You to weymouthstan For This Useful Post: | ||
 |
|
2009-12-20
, 18:10
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#18
|
I personally think too that autooptification should be the best method for your average app: it's easy, doesn't break too many things, can be reverted easily and allows to easily rebuild the package for Diablo in case the need arises (as you can see the keyword here is "easy" 
).
Of course, if your app is pretty much self-contained in a non-Unixy way, "manual" optification might be easier (most commercial apps...).
I've used the preinst link method in openttd cause my personal use case is to symlink it to the mmc card (like on Diablo), but still allow for package upgrades. Since I plan to keep the install-to-card trick in the Diablo version, it's also the most convenient way to share source packages between both.
).Of course, if your app is pretty much self-contained in a non-Unixy way, "manual" optification might be easier (most commercial apps...).
I've used the preinst link method in openttd cause my personal use case is to symlink it to the mmc card (like on Diablo), but still allow for package upgrades. Since I plan to keep the install-to-card trick in the Diablo version, it's also the most convenient way to share source packages between both.
| The Following User Says Thank You to javispedro For This Useful Post: | ||
|
|
2009-12-20
, 18:11
|
|
Posts: 1,208 |
Thanked: 1,028 times |
Joined on Oct 2007
|
#19
|
Originally Posted by VDVsx
All files are under packaging system control. Of course having thousands of links is not that good, but it only happens when package name and directory name are not the same (which often happens with -data packages)
Well, I also don't want to see thousands of symlinks in my system pointing to /opt/...,
Originally Posted by VDVsx
I am not against using /opt directly (actually I'm for it), but I am recommending maemo-optify for everyone who hasn't heard about /opt problem before (I don't mean lcuk here, but everyone who happens to read this). And I'm definitely for /opt and maemo-optify over any other method
You can also check the -devel ML archive where the maemo-optify author suggested the "better method".
|
|
2009-12-20
, 18:14
|
|
Posts: 1,208 |
Thanked: 1,028 times |
Joined on Oct 2007
|
#20
|
Originally Posted by weymouthstan
Yes it does
Noob question from someone who's just done his second reflash after installing too many unoptified apps :
As an end-user, If a new, optified version version of a previously un-optified app is installed, does it automatically tidy up the files that the un-optified version had created, and free up the filespace?
| The Following User Says Thank You to mikkov For This Useful Post: | ||
For everyone who is thinking about "how to optify", try maemo-optify first and then think about something else if there's a need for that.