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
