New optification issues in extras-testing
Till Harbaum / Lists
lists at harbaum.org
Tue Dec 29 21:49:21 EET 2009
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
More information about the maemo-developers
mailing list