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

[From: Marius Vollmer]

ext Andrew Flegg <andrew at bleb.org> writes:

> On Thu, Sep 10, 2009 at 16:12, Marius Vollmer <marius.vollmer at nokia.com> wrote:
>> ext Andrew Flegg <andrew at bleb.org> writes:
>>>
>>> Instead of using a fixed prefix of /opt/maemo/<path>, use
>>> /opt/<package>/<trimmed path>.
>>
> [big snip]
>
> I'm not going to get into a point-by-point rebuttal of these.

Hmm, I am really in a detail-oriented "let's get this done" mode.  As I
said, the question of whether or not and if so how to use /opt for
distribution packages is bigger than this, and I don't think we should
try to answer it here.

People haven't really used /opt in their packages until now, and nothing
really has changed to reconsider this on a massive scale.  The name
"/opt" that appears in this discussions is a big giant red herring.
Just pretent it really was "/space" all the time, and I hope you can see
how different the discussion would have been.

> But installing stuff in /opt on Maemo by third-parties isn't really
> going to happen.

Maybe not, but that's no reason to repurpose the whole of /opt.  You
could also say that Maemo will never really be multi-user, but that's no
reason to get rid of /home/user.

> We own the space, pretty much everything is going to be installed from
> packages, and we already make all manner of assumptions in a Linux
> system that there's some unique "UNIX name" for a package.  Why *not*
> make the one-line change to maemo-optify to make its results slightly
> cleaner?

Because it's not cleaner in my view, it would be an even bigger abuse of
/opt than hiding things in /opt/maemo.

If you really care, we can make this an option to maemo-optify, and you
can use it in your packages.  I will still recommend the default of just
moving everything to /opt/maemo without any further distortion.

>>  - Computing the <trimmed path> from <path> is an extra complication,
>>   and we must make sure that no collisions happen.  It's doable of
>>   course, but in the light of the arguments above, why bother?
>
> ...because /opt is a hack because no-one at Nokia had the foresight to
> imagine that users might want to install multiple applications, and
> large new frameworks like Qt.

The "/opt is hack" statement needs to be qualified, of course.  "Moving
stuff into /opt/maemo" is a hack, of course.  But at least in my
opinion, "Moving stuff into /opt/<package>/" is a bigger hack, and a
bigger violation of the letter and spirit of /opt. *shrug*

> ...because /opt is a hack which should be *embarassing*.

It is!

> ...because maemo-optify creating a forest of symlinks is messy,
> unelegant and possibly prone to failure (see my earlier question about
> Python modules and sub-directories of optified packages).

If I understand your proposal here right, we would still have the same
forest of symlinks, just more messy since they have a more complicated
pattern.

> Mainly, though, because last minute fixes shouldn't throw good design
> out of the window.

I don't think using /opt/<package> in distribution packages is good
design.