MeeGo Compliance: Why installing to /opt is a Good Thing

March 24, 2011

The current MeeGo Compliance Spec will often give developers a start when they read this:

An application shall be installed to /opt/packagename/ and, if necessary to the /etc/opt/packagename/ and /var/opt/packagename/ directories.[1]

Most users reply, “Huh?  Why don’t we install in /usr like a normal Linux distro??”  The rationale is given as follows:

The rationale for these rules is to avoid filename clashes between application packages and with system files, by defining portions of the filesystem certain to be unique to that application.[2]

This leaves most devs a little… underwhelmed.  The first response is to appeal to the FHS/LSB… but lets start with an example.

Suppose I write a MeeGo game called “Zombie Professer Shootout.”  Because I’ve got several modules for this game, I have an internal library called  Because I don’t know any better, I install it in /usr/lib/  Put the package in the App Store.  Done.

Meanwhile, suppose that YOU, Zeek, write a hand MeeGo time management program called “Zeek’s Personal Scheduler.”  For whatever reason, you put a lot of the core functionality in a library called so that other people could reuse it in their code.  So, you install it to /usr/lib/  Put the package in the App Store.  Done.

First, they install my Zombie game.  Then, months later, they install your Personal Scheduler.  However, the app WILL NOT install because it would overwrite /usr/lib/  There’s no way around it.  You have a broken package.

And the user says, “This sucks!”

The whole point of being a MeeGo compliant app is that it’s a single, stand-alone, 3rd party app that can be installed to MeeGo… and it Just Works.  But if we all install in /usr… then we all have to be on the same page with respect to file names, package names, etc.  In a normal linux distro (where all packages are served from one repository), these get discovered and discussed among the developers.  But with MeeGo apps coming from a myriad of sources there is no way that can happen.

So, MeeGo chose to use namespaces by requiring installation to /opt.  The opt folder is defined in the FHS as follows:

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider’s LANANA registered name.[3]

Note that this is nearly identical to the MeeGo requirement… and serves to solve this exact problem.  It’s a system that allows uncoordinated developers the freedom to organize their package however they need without stepping on anyone else’s toes.  Everything they do is under the namespace of the company’s LANANA registered name (e.g. or something).  Without this, users will be inundated with broken packages and always come to the same conclusion: “This sucks.”

“But how do I find my project’s libs?  What about $PATH?  This is no fun for the developer!”  We’ll talk about that next time.

[1] MeeGo 1.1 Compliance Specification, Section 3.3.4

[2] Ibid.



2 Responses to “MeeGo Compliance: Why installing to /opt is a Good Thing”

  1. […] last time I convinced you that packaging for /opt is a Good Thing for add-on software (e.g. app store […]

  2. […] Visit link: MeeGo Compliance: Why installing to /opt is a Good Thing « Gabe's … […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: