[maemo-developers] maemo-optify, autobuilder & /opt

[From: Ed Bartosh]

2009/10/29 Andrew Flegg <andrew at bleb.org>:
> Ed wrote:
>> 2009/10/29 Graham Cobb <g+770 at cobb.uk.net>:
>> >
>> > Nobody likes doing something to the package automatically but, after a long
>> > discussion at the BOF, we agreed that the alternatives were even worse [1].
>> >
>> Then let's find the way to do it better.
>> What I'm afraid of is that developers wouldn't like the approach to
>> change packages implicitly.
>
> There were some very "senior" and well respected developers in the room, who package some of the leading Maemo applications.
>
>> It potentially can create repository mess
>> again. And I really don't want this to happen.
>
> No-one does, however increasing the amount of work developers have to do to get into Extras because of Nokia's short-sightedness is also a demotivating factor which could lead to multiple repositories springing up.
>
True. However I'm not sure that making developers to do additional
work is worse than change package imlicitly, which can potentially
cause installation and runtime problems.

>> > In particular, there was a strong argument that the package should not have to
>> > include anything (even a control field option) to cause optification to
>> > happen.  Packages which wanted to do their own optification or which had to
>> > disable optification would have to include an option to stop optification.
>
> And this is because /opt is basically a weirdness caused specific to Maemo packaging, and (with the move to Qt) the Maemo development community is increasingly realising the benefits of abstracting platform weirdness.
>
>> Would it be better to change the common part of developer environment
>> and autobuilder, for example somewhere in debian devkit? If
>> dpkg-buildpackage will produce optified packages they will be at least
>> the same everywhere.
>
> Have you an estimate on the comparative costs of developing one vs. the other? This is an implementation detail of "make the autobuider" do it. Who owns the Debian devkit and do they want to do the work?
>
I'd say changing devkit would take twice more then modifying
autobuilder. Not a very big difference, considering that  we can have
one solution to both problems. With modified devkit we can change both
developer and autobuider environments in one shot.

Devkit is a part of SDK, so SDK people own it.
I can help to modify it if we decide to go this way.

> A "maemo-buildpackage" was mentioned in the BOF as a potential way of allowing developers to do what the auto-builder does. How hard would it be to develop this and get the autobuilder to call maemo- rather than dpkg-buildpackage?
>
> However, there seem to be two arguments on your side:
>
>  1) Don't do anything, developers should modfy
>     debian/rules as they do now.
>  2) Make something in the build process do it,
>     rather than the autobuilder.
>
I like 1st better. Second is just a bit better alternative to your decision.

> (2) is an internal implementation detail which isn't important externally: the consensus view could be tested by uploading a Diablo source package with no changes and having it auto-optified. Whether that's through a change to the devkit, autobuilder-specific code or the introduction of maemo-buildpackage is of little interest to the person doing the uploading :-)
>
It is important. Instead of introducing new tool we just change the
existing. No additional work for developers in this case.


-- 
BR,
Ed