[maemo-developers] Considering /opt and MyDocs in your packages

[From: Andrew Flegg]

On Thu, Sep 10, 2009 at 09:05, Marius Vollmer <marius.vollmer at nokia.com> wrote:
> ext Graham Cobb <g+770 at cobb.uk.net> writes:
>
>> Hmm.  Are there some objective criteria for what should go in opt?
>
> Not really.  The proposed tool, maemo-optify, has a hard-coded, builtin
> heuristic to select which files to move.  It is supposed to be a
> fire-and-forget action: you add a simple call to maemo-optify to
> debian/rules, and the heuristic does the right thing.
>
> The current heuristic moves files that are larger than 2 kiB, and
> directories that are larger than 2 kiB and are named like the package.
> This is the output for ecoach, for example:
>
>    $ maemo-optify-deb ecoach_1.53beta3_i386.deb
>    usr/bin/ecoach -> opt/maemo/usr/bin/ecoach
>    usr/share/ecoach -> opt/maemo/usr/share/ecoach
>    usr/share/icons/hicolor/scalable/hildon/ecoach.png -> \
>      opt/maemo/usr/share/icons/hicolor/scalable/hildon/ecoach.png
>    usr/share/pixmaps/ecoach -> opt/maemo/usr/share/pixmaps/ecoach
>    ecoach: optified 4 entries, saving about 546 kB.

Definitely auto=adding a call to maemo-optify is something that MUD
might do (as Graham already suggested), and I agree it's something
which shouldn't be done at the autobuilder (at least until it becomes
a problem that no-one's using /opt).

However, I'd love to see the output above be:

    $ maemo-optify-deb ecoach_1.53beta3_i386.deb
    usr/bin/ecoach -> opt/ecoach/bin/ecoach
    usr/share/ecoach -> opt/ecoach/share/ecoach
    usr/share/icons/hicolor/scalable/hildon/ecoach.png -> \
      opt/ecoach/share/icons/hicolor/scalable/hildon/ecoach.png
    usr/share/pixmaps/ecoach -> opt/ecoach/share/pixmaps/ecoach
    ecoach: optified 4 entries, saving about 546 kB.

In this, I thought about usr/share/ecoach -> opt/ecoach/share, but it
introduces problems and over-complications with .../share/pixmaps and
.../icons.

What do you think Marius?

> In light of the recent discussion, the 2 kiB threshold is maybe a bit
> low.

Indeed. What's the disk space usage of a symlink? ;-)

> Of course, we should add some way to control the heuristic of
> maemo-optify, but I think it is important that it does something
> reasonably by default.

Absolutely (hence my keenness on it being more FHS compliant by using
the package name).

Cheers,

Andrew

-- 
Andrew Flegg -- mailto:andrew at bleb.org  |  http://www.bleb.org/
Maemo Community Council chair