Michael Hall <mhall...@ubuntu.com> wrote:
>
>On 09/04/2012 06:05 PM, Scott Kitterman wrote:
>> On Tuesday, September 04, 2012 01:19:50 PM Michael Hall wrote:
>>> 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/.
>>
>> These sorts of changes should be generalizable to be supported at
>build time.
>> It would take some work to set up the first time, but any build
>system I've
>> worked with would be able to do this.
>>
>> Scott K
>>
>To support them at build-time, you end up having to make various
>changes
>to the original source. For example, a typical foo.desktop file will
>contain the following lines:
>
>Icon=foo
>Exec=foo
>
>Now, if the app has to be installed into /opt/extras.ubuntu.com/foo/,
>those lines will need to be changed to:
>
>Icon=/opt/extras.ubuntu.com/foo/foo.png
>Exec=/opt/extras.ubuntu.com/foo/bin/foo
>
>Which requires running sed against foo.desktop using overrides in
>debian/rules. We need to do this for DBus services and Unity lenses
>and
>scopes as well. Other build-time hacks are required to support
>translations in /opt/, and apport crashdb. None of these are
>especially
>difficult, but they accumulate into a large number of changes for even
>the most basic application.
>
>I have attached an example debian/rules file from one of the App
>Showdown entries. This was a simple python app with a valid setup.py,
>built using Quickly. You can see how much it's having to change to
>install into /opt/, and this was typical of all App Showdown
>debian/rules files.
>
>In addition, a quick scan of the source for some of those apps shows a
>number of places where paths to /opt/ are being hard-coded elsewhere in
>the source. I know this isn't something they should be hard-coding,
>but
>these are the kind of independent app developers we want to target
>Ubuntu and this is what they are likely going to keep doing in order to
>support having their app installed in /opt/.
It is quite common for upstreams to make their code less portable than they
might. One of the basic reasons make exists is to allow building code in
portable ways. It doesn't surprise me a bit the code isn't written to be
portable, but that's doesn't mean it can't be.
Scott K
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
