Re: New optification issues in extras-testing
Till Harbaum / Lists wrote: Hi, Am Mittwoch 30 Dezember 2009 schrieb Alberto Mardegan: This is my goal, but please move them in the 32GB storage. :-) Oh, i see what you mean. Urgh ... that's a tricky one as moving them for one app will break the other one. I don't think it's such a big problem: in the post-install script of the updated applications we can have a test that checks if the old tile directory exists (and is a regular dir, not a symlink) and if so copies all the tiles into the new location, and then removes the old dir and makes it a symbolic link to the new location. (the 32GB storage is FAT32 so it cannot have symlinks, but /home is ext3 so it should work) Ciao, Alberto -- http://www.mardy.it - geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, Am Freitag 01 Januar 2010 schrieb Alberto Mardegan: directory exists (and is a regular dir, not a symlink) and if so copies all the tiles into the new location, and then removes the old dir and makes it a symbolic link to the new location. Yes, that what i also came up with after some thinking. The only issue: This may take some time. I e.g. have ~150MB in that directory. The user may think the installation hangs if i move that much data. So some dialog has to be presented to the user. Ciao, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, Am Mittwoch 30 Dezember 2009 schrieb Alberto Mardegan: This is my goal, but please move them in the 32GB storage. :-) Oh, i see what you mean. Urgh ... that's a tricky one as moving them for one app will break the other one. Regards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Till Harbaum / Lists wrote: i have just been instructed to reduce the size of osm2go _incl._ its depending libraries to under 500k: Speaking of which, it would be nice if you instructed osmgpsmap to store the tiles under /home/user/MyDocs/.maps/ so that they could be shared with maemo-mapper (I probably need to modify it a bit so that the repository names are the same that osmgpsmap uses). Or please let me know if you have a better proposal. Ciao, Alberto -- http://www.mardy.it - geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, Am Dienstag 29 Dezember 2009 schrieb Jeff Moe: You should do so, so your users don't brick their phones. It's soo easy to put everything in /opt. I agree the symlinking madness is a bit messy, but it workz and it's what we are stuck with until we have 2G NANDs. In fact i just thought that i can put the binary in opt and reference it directly from the .desktop file without putting a symlink into /usr/bin I'll do that in the next release (although i don't have a clue how you expect my program to brick a phone by not doing so). Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, Am Mittwoch 30 Dezember 2009 schrieb Alberto Mardegan: Speaking of which, it would be nice if you instructed osmgpsmap to store the tiles under /home/user/MyDocs/.maps/ so that they could be shared with maemo-mapper (I probably need to modify it a bit so that the repository names are the same that osmgpsmap uses). Uhm, maemo mapper has only recently been ported to maemo5. When i came up with my naming scheme i was the only one storing map tiles that way. Changing things now would mean that all of my apps have to cleanup the old paths and convert the to the new scheme while at the same time making sure that they don't affect maemo mapper etc etc ... With maemo mapper being in a such early state of development i am hesitating to adopt to its rules. And finally: Since when does maemo mapper store plain tiles at all?? Doesn't it store everything in databases (even in varying sqlite or gnudb format)? Or please let me know if you have a better proposal. I am definitely willing to work on this. But today maemo mapper seems to be far from even alpha quality, so i am not sure if i want to change my apps already being in extras to deal with the map tiles repositories of a pre-beta version from extras-devel. What about making maemo mapper deal with my repositories? I very likely by now have the bigger installed user base and thus have to expect more trouble during such a transition. Regards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi Till, Till Harbaum / Lists wrote: Am Mittwoch 30 Dezember 2009 schrieb Alberto Mardegan: Speaking of which, it would be nice if you instructed osmgpsmap to store the tiles under /home/user/MyDocs/.maps/ so that they could be shared with maemo-mapper (I probably need to modify it a bit so that the repository names are the same that osmgpsmap uses). Uhm, maemo mapper has only recently been ported to maemo5. When i came up with my naming scheme i was the only one storing map tiles that way. Changing things now would mean that all of my apps have to cleanup the old paths and convert the to the new scheme while at the same time making sure that they don't affect maemo mapper etc etc ... I'm not proposing a different naming scheme: the one you osmgpsmap uses is fine, what I don't like is the base dir used by ecoach: IIRC, it's storing the tiles under /home/user and not on the 32GB flash (which is /home/user/MyDocs/). Then, the tiles need to be under a directory whose name starts with a dot, so that tracker won't index them. And finally: Since when does maemo mapper store plain tiles at all?? Doesn't it store everything in databases (even in varying sqlite or gnudb format)? I changed that: this way the code is much cleaner, it's at least as fast and we can share the tiles with other apps. What about making maemo mapper deal with my repositories? I very likely by now have the bigger installed user base and thus have to expect more trouble during such a transition. This is my goal, but please move them in the 32GB storage. :-) Ciao, Alberto -- http://www.mardy.it - geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Wednesday 30 December 2009 16:13:19 Till Harbaum / Lists wrote: Am Dienstag 29 Dezember 2009 schrieb Jeff Moe: You should do so, so your users don't brick their phones. It's soo easy to put everything in /opt. I agree the symlinking madness is a bit messy, but it workz and it's what we are stuck with until we have 2G NANDs. In fact i just thought that i can put the binary in opt and reference it directly from the .desktop file without putting a symlink into /usr/bin I'll do that in the next release (although i don't have a clue how you expect my program to brick a phone by not doing so). If it is the package that is the final straw that pushes a user to 100% full filesystem, next time they boot, their system will be bricked. This has happened to *many* users with a variety of packages (I don't know of any cases of it happening with yours, but it can happen with any package that writes to the NAND). There are lots of reports of people bricking due to full NAND on talk.maemo.org, for example. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
New optification issues in extras-testing
Hi, i have just been instructed to reduce the size of osm2go _incl._ its depending libraries to under 500k: http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138 Guys, i really hate the fact that you come up with new rules every three days. I have already had complains about doesn't look nice enough, won't run on maemo6 and now this. Please either a) make the all-libs-together-have-to-stay-under-500k an explicit rule for extras and i'll consider following that rule, or b) just delete that thumbs-down if it's not appropriate and make clear that it's not required that all components together stay under 500k Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, sorry, the link was truncated. I am talking about: http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138713 Additional info: There already is a version in extras that is exceeding these new limits. The new version fixes some bugs. So the new version gives no disadvantage over the version currently in extras. Delaying it just prevents the bug fixes to reach the end users. Till Am Dienstag 29 Dezember 2009 schrieb Till Harbaum / Lists: Hi, i have just been instructed to reduce the size of osm2go _incl._ its depending libraries to under 500k: http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138 Guys, i really hate the fact that you come up with new rules every three days. I have already had complains about doesn't look nice enough, won't run on maemo6 and now this. Please either a) make the all-libs-together-have-to-stay-under-500k an explicit rule for extras and i'll consider following that rule, or b) just delete that thumbs-down if it's not appropriate and make clear that it's not required that all components together stay under 500k Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Am Dienstag, den 29.12.2009, 13:18 +0100 schrieb Till Harbaum / Lists: http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138 Error 404: Page could not be found. Probably https://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/osm2go/0.8.1-maemo1/ Guys, i really hate the fact that you come up with new rules every three days. Who exactly is you in your sentence? According to the ChangeLog, 500k has been listed at http://wiki.maemo.org/Extras-testing/QA_Checklist since Oct 22nd, 2009. Maybe you meant two months instead of three days? andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, the page you are referring to says: The application or its dependencies ignore the recommendation to use the eMMC to install as much files as possible, filling the root partition with 500kb or more. It does not say that the _sum_ of all dependencies has to be below 500k. This rule that the sum of all components also has to stay below a certain limit is new. Osm2go is below 500k and so is the goocanvas it depends on. Now this guy is talking about the fact that the sum is over 500k. Till Am Dienstag 29 Dezember 2009 schrieb Andre Klapper: Am Dienstag, den 29.12.2009, 13:18 +0100 schrieb Till Harbaum / Lists: http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138 Error 404: Page could not be found. Probably https://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/osm2go/0.8.1-maemo1/ Guys, i really hate the fact that you come up with new rules every three days. Who exactly is you in your sentence? According to the ChangeLog, 500k has been listed at http://wiki.maemo.org/Extras-testing/QA_Checklist since Oct 22nd, 2009. Maybe you meant two months instead of three days? andre ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tuesday 29 December 2009 14:01:40 Till Harbaum / Lists wrote: This rule that the sum of all components also has to stay below a certain limit is new. Osm2go is below 500k and so is the goocanvas it depends on. Now this guy is talking about the fact that the sum is over 500k. Any limit that includes dependencies will simply not work as there is no guarantee (except with the rare exception where the developer is maintainer of ALL the dependencies as well) what amount of space will be used on the NAND. Different versions might have different optification rules, they might grow or shrink, include additional dependencies of their own, etc. A source of misunderstanding might be the wording of the requirement: The application or its dependencies ignore the recommendation to use the eMMC to install as much files as possible, filling the root partition with 500kb or more. I can see how this can be interpreted both ways - both total and per package. As IMHO there is no point in the former (see above), and if there is a consensus about this it should perhaps be corrected that the per-package context of the 500K is clear(er). A broader question is if the 500K as a *number* should be part of the blocker paragraph. AFAIK the 500K is a guideline (unless 'encouraged' became a synonym with 'required'), what we are (supposed to be ?) looking at here is the general principle of avoiding *unnecessarily* wasting resources. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tue, Dec 29, 2009 at 13:01, Till Harbaum / Lists li...@harbaum.org wrote: the page you are referring to says: The application or its dependencies ignore the recommendation to use the eMMC to install as much files as possible, filling the root partition with 500kb or more. It does not say that the _sum_ of all dependencies has to be below 500k. I agree, it looks ambiguous. The *intent* seems to be that installing an application shouldn't take up more than 500KB of the rootfs (your Python example on the package page is specious, BTW, as Python is now optified). If the dependencies are used by lots of apps, and have separate maintainers; I can understand your point. However, since: * you maintain both libgoocanvas3 and osm2go * neither are optified (according to the comments) * I *imagine* there aren't lots of other apps depending on libgoocanvas3 which have been let through QA ...this would seem to fall on to your shoulders. The STRONG recommendation is that EVERYTHING is optified, and getting pedantic about the numbers when you control both halves of the application stack seems a little churlish. After all, someone wanting to be difficult could split their app into 500 2KB packages which depend on each other :-) Now, on to solving the problem, have you tried putting auto in debian/optify? If so, did both packages continue to work after being auto-optified by the builder (or maemo-build-deb in Scratchbox, if you prefer). The intention is that they *should* (which is why 'auto' will become the default at some point in the future). Hope that helps, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
ext Attila Csipa ma...@csipa.in.rs writes: A broader question is if the 500K as a *number* should be part of the blocker paragraph. [...] I think the only sane thing to do is to look at the ratio of files in /opt to those not in /opt, and require that ratio to be at least the same as the ratio of the space in /opt to the one in /. Maemo-optify could be changed to move as many files into /opt as needed to meet this requirement, starting from the biggest. It's on my todo list... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tuesday 29 December 2009 11:03:01 Marius Vollmer wrote:
ext Attila Csipa ma...@csipa.in.rs writes:
A broader question is if the 500K as a *number* should be part of the
blocker paragraph. [...]
I think the only sane thing to do is to look at the ratio of files in
/opt to those not in /opt, and require that ratio to be at least the
same as the ratio of the space in /opt to the one in /.
Maemo-optify could be changed to move as many files into /opt as needed
to meet this requirement, starting from the biggest. It's on my todo
list...
I don't understand why maemo-optify doesn't just move *everything* to /opt,
including files under 2k etc. What advantage does it give to not have them in
/opt? For instance, I ran into this problem with asterisk where it had many
small sound files which still put 600k on the NAND.
-} elsif ($size = 2048) {
+} elsif ($size = 0) {
...
In sum, what is the upside of including anything but symlinks on the NAND?
IMHO, it should punt everything to /opt as long as it is needed at all.
Thanks for maemo-optify, it makes things so much lazier^H^H...easier. :)
-Jeff
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, ext Andrew Flegg wrote: The application or its dependencies ignore the recommendation to use the eMMC to install as much files as possible, filling the root partition with 500kb or more. It does not say that the _sum_ of all dependencies has to be below 500k. I agree, it looks ambiguous. The *intent* seems to be that installing an application shouldn't take up more than 500KB of the rootfs (your Python example on the package page is specious, BTW, as Python is now optified). If the dependencies are used by lots of apps, and have separate maintainers; I can understand your point. However, since: * you maintain both libgoocanvas3 and osm2go * neither are optified (according to the comments) * I *imagine* there aren't lots of other apps depending on libgoocanvas3 which have been let through QA Where this 500kB figure for these packages come from? If it's uncompressed size, then it's bogus as the rootfs is compressed. The script attachment here: https://bugs.maemo.org/show_bug.cgi?id=5795 Tries to give a more realistic[1] estimate on how much space a package actually takes from the rootfs. - Eero [1] Note that the documentation is removed with an apt hook. If one installs package directly with dpkg to the device, this hook doesn't get called. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Jeff Moe on 12/29/2009 08:20 AM wrote:
I don't understand why maemo-optify doesn't just move*everything* to /opt,
including files under 2k etc. What advantage does it give to not have them in
/opt? For instance, I ran into this problem with asterisk where it had many
small sound files which still put 600k on the NAND.
-} elsif ($size= 2048) {
+} elsif ($size= 0) {
Submit a patch to maemo-optify[1]. This is a must. Only kernel/Nokia
libraries should be on the rootfs. With so little space, there is no
reason for any end-user or commercial generated content to be on the rootfs.
[1] http://gitorious.org/+maemo-af-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hallo! In sum, what is the upside of including anything but symlinks on the NAND? IMHO, it should punt everything to /opt as long as it is needed at all. Thanks for maemo-optify, it makes things so much lazier^H^H...easier. :) Symlinks take space on disk, too. I'm not sure if they take a whole block or a part of it but there is likely a limit where a links costs more space than the data itself. Is this where the 2K come from? We also should keep care that we do not run out of inodes (which IMHO should not be a problem if we replace the real file with a link because that does/should not increase the amount of inodes). -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tue, 2009-12-29 at 16:57 +0100, ext Tim Teulings wrote: Hallo! In sum, what is the upside of including anything but symlinks on the NAND? IMHO, it should punt everything to /opt as long as it is needed at all. Thanks for maemo-optify, it makes things so much lazier^H^H...easier. :) Symlinks take space on disk, too. I'm not sure if they take a whole block or a part of it but there is likely a limit where a links costs more space than the data itself. Is this where the 2K come from? Perhaps it's the time to symlink directories ? ;-) Cheers, -- Senior Software Engineer Maemo Software ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tuesday 29 December 2009 13:07:36 Mohammed Hassan wrote: On Tue, 2009-12-29 at 16:57 +0100, ext Tim Teulings wrote: Hallo! In sum, what is the upside of including anything but symlinks on the NAND? IMHO, it should punt everything to /opt as long as it is needed at all. Thanks for maemo-optify, it makes things so much lazier^H^H...easier. :) Symlinks take space on disk, too. I'm not sure if they take a whole block or a part of it but there is likely a limit where a links costs more space than the data itself. Is this where the 2K come from? I didn't check for sure, but I don't think symlinks take anywhere near 2k. Perhaps it's the time to symlink directories ? ;-) ln -s /opt/etc /etc/opt http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCOPTCONFIGURATIONFILESFOROPT But a bit OT. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Jeff Moe on 12/29/2009 08:20 AM wrote: Symlinks take space on disk, too. I'm not sure if they take a whole block or a part of it but there is likely a limit where a links costs more space than the data itself. Is this where the 2K come from? An inode on the default file system is only 256 bytes. Ext was optimized for small files and fast symlinks. We also should keep care that we do not run out of inodes (which IMHO should not be a problem if we replace the real file with a link because that does/should not increase the amount of inodes). With only 2 gigs of space by default, you are not going to run out of inodes. This discussion should have been long ago prior to Maemo 5's release and not now. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi,
it's likely wait too late for such a question, but why doesn't just /opt/bin,
/opt/share etc exist with the system looking into those paths as well?
Noone would have to care about optification then, no symlinks would
be required and most packages could just be optified by configure
--prefix=/opt.
I must be missing a very obvious thing that makes the current solution
better/nicer/whatever.
Till
Am Dienstag 29 Dezember 2009 schrieb Michael Cronenworth:
Jeff Moe on 12/29/2009 08:20 AM wrote:
I don't understand why maemo-optify doesn't just move*everything* to /opt,
including files under 2k etc. What advantage does it give to not have them
in
/opt? For instance, I ran into this problem with asterisk where it had many
small sound files which still put 600k on the NAND.
-} elsif ($size= 2048) {
+} elsif ($size= 0) {
Submit a patch to maemo-optify[1]. This is a must. Only kernel/Nokia
libraries should be on the rootfs. With so little space, there is no
reason for any end-user or commercial generated content to be on the rootfs.
[1] http://gitorious.org/+maemo-af-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, Am Dienstag 29 Dezember 2009 schrieb Eero Tamminen: Where this 500kB figure for these packages come from? As long as there's no indication whether the limit itself is meant to be interpreted as logical or physical memory space there's imho no point of discussing what this guy actually measured. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, Am Dienstag 29 Dezember 2009 schrieb Andrew Flegg * you maintain both libgoocanvas3 and osm2go Still this would require additional work i'd like to avoid. * neither are optified (according to the comments) Osm2go is of course optified, otherwise it wouldn't already be in extras. Just the stuff the system needs symlinks for is still in rootfs as i really think this excessive symlinking is ugly as hell. * I *imagine* there aren't lots of other apps depending on libgoocanvas3 which have been let through QA Xournal? ...this would seem to fall on to your shoulders. The STRONG recommendation is that EVERYTHING is optified, and getting pedantic about the numbers when you control both halves of the application stack seems a little churlish. After all, someone wanting to be difficult could split their app into 500 2KB packages which depend on each other :-) Then why do you talk about a 500kB limit if you in fact want _everything_ in /opt? What's the point of giving hard numbers and then stating that you want something different? Now, on to solving the problem, have you tried putting auto in debian/optify? If so, did both packages continue to work after being auto-optified by the builder (or maemo-build-deb in Scratchbox, if you prefer). Why should i? I think the 500k per package limit is fine and neither of my two packages exceeds it. There is a rule, i am following it and that's it. If you don't like the rule, then change it. If you think my interpretation of the rule is valid but not what it intends to say, then re-phrase the rule to become clear. If you want to do neither: Accept my interpretation. The intention is that they *should* (which is why 'auto' will become the default at some point in the future). That's the moment where i'll have to deal with it. Not before. As i said above: I think the current 500k limit per package is just fine, so for me this is just an unnecessary hurdle. Hope that helps, Andrew Regards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tue, Dec 29, 2009 at 19:49, Till Harbaum / Lists li...@harbaum.org wrote: Am Dienstag 29 Dezember 2009 schrieb Andrew Flegg * you maintain both libgoocanvas3 and osm2go Still this would require additional work i'd like to avoid. Well, the creation of debian/optify containing the one word auto shouldn't be *too* much work. * neither are optified (according to the comments) Osm2go is of course optified, otherwise it wouldn't already be in extras. Just the stuff the system needs symlinks for is still in rootfs as i really think this excessive symlinking is ugly as hell. I entirely agree! maemo-optification is a HIDEOUS hack (the thread where /opt was unveiled contains my thoughts); but it's the easiest way to solve the problem for authors who don't want to do too much work, and the most expedient for Nokia as they realised the problem *far* too late. * I *imagine* there aren't lots of other apps depending on libgoocanvas3 which have been let through QA Xournal? OK. Unfortunately, the packages interface doesn't let you see reverse dependencies ATM. ...this would seem to fall on to your shoulders. The STRONG recommendation is that EVERYTHING is optified, and getting pedantic about the numbers when you control both halves of the application stack seems a little churlish. After all, someone wanting to be difficult could split their app into 500 2KB packages which depend on each other :-) Then why do you talk about a 500kB limit if you in fact want _everything_ in /opt? What's the point of giving hard numbers and then stating that you want something different? Who is this you? Do you see my name on the comments page?[1] Why should i? I think the 500k per package limit is fine and neither of my two packages exceeds it. There is a rule, i am following it and that's it. If you don't like the rule, then change it. If you think my interpretation of the rule is valid but not what it intends to say, then re-phrase the rule to become clear. If you want to do neither: Accept my interpretation. Why the confrontational approach? Why this you sort it out attitude? That's the moment where i'll have to deal with it. Not before. As i said above: I think the current 500k limit per package is just fine, so for me this is just an unnecessary hurdle. OK, so when that switches to automatic, can we have it in writing that you won't be on this list complaining about us changing the rules and breaking your packages? Of course, one *hope's* it'll work for libgoocanvas3 or osm2go, but it wouldn't work for Python (due to the way it uses readlink during library determination), so the odds are it not working on *all* packages. Cheers, Andrew [1] I'm fed up of being castigated by a small majority in this community for trying to help people understand the actions of others. -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tuesday 29 December 2009 16:49:21 Till Harbaum / Lists wrote: Now, on to solving the problem, have you tried putting auto in debian/optify? If so, did both packages continue to work after being auto-optified by the builder (or maemo-build-deb in Scratchbox, if you prefer). Why should i? I think the 500k per package limit is fine and neither of my two packages exceeds it. You should do so, so your users don't brick their phones. It's soo easy to put everything in /opt. I agree the symlinking madness is a bit messy, but it workz and it's what we are stuck with until we have 2G NANDs. Do it for the users, not for some QA list. :) -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
ext Till Harbaum / Lists li...@harbaum.org writes: it's likely wait too late for such a question, but why doesn't just /opt/bin, /opt/share etc exist with the system looking into those paths as well? My gut feeling is that this is not feasible in the short term, and not good enough for the long term. It is not feasible in the short term since it likely requires many iterations of the OS itself in order to get this to work reasonably well, and OS iterations are unfortunately just too damn slow. That's my feeling at least, and I was looking for a 'solution' that didn't require changes to the OS itself. (Incidentally, we shouldn't have made the /opt - /home/opt symlink either, we should just have 'homeified' packages to /home/maemo. The symlink has caused more than its share of problems...) Now, in the long run, I hope we do not have to do any of this. The rootfs should just be large enough, either by putting it on a single big partition, or by combining multiple partitions transparently with some kind of unionfs, lvm, or by just mounting /usr from a second partition. This allows us to stay compatible with the rest of the world, and is what common sense dictates. (The current plan is to have one big partition for /, but only for Harmattan.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
