Proposing a New App Developer Upload Process

[Michael Hall]

On 09/04/2012 01:02 PM, Emmet Hikory wrote:
> Michael Hall wrote:
>> Not only would it require the we carry these patches to system tools and
>> libraries indefinitely, it would also mean that we encourage developers
>> to produce apps and packages that are not compatible with our Upstream
>> (Debian) or any other distro.
> 
>     We rather ought encourage developers to use build systems that allow
> one to specify an install location: then the difference between installing
> to /opt/ and system locations becomes entirely a matter of a preference in
> the packaging: other format distributions will not even notice.  Distributions
> that use Debian-format packages are likely to be downstream from either Debian
> or Ubuntu: if we share the optional /opt/ packaging preference with Debian,
> then it is trivial for any distribution to adopt the package as either extra
> or part of the system with very little effort.
> 
If it can be reduced to a matter of build-time preferences, that would
be fine.  The current /opt/ rules and support, however, require both a
significant amount of extra work in the packaging, and usually
additional changes to the code itself.

>     As for patches in system tools, at least for icon cache, path, and desktop
> file discovery, this is one or two lines in a configuration file that already
> carries Ubuntu-specific patches.  Is there a specific example of a discovery
> mechanism that is more complicated to change?
> 
.desktop files, .service files (for dbus), .lens and .scope files (for
Unity) all needed to be changed to point to executables or images in
/opt/extra.ubuntu.com/${appname}/ when being packaged for Extras.  Unity
APIs that require a .desktop or image file name had to use absolute
paths to the files in /opt/extras.ubuntu.com/{$appname}.  These all
required changes to the app's source in order to support the
installation under /opt/.


Michael Hall
mhall119 at ubuntu.com