2009/10/29 Graham Cobb <g+...@cobb.uk.net>:
> On Wednesday 28 October 2009 22:50:25 Ed Bartosh wrote:
>> Somehow I don't like the idea of doing anything with the package
>> without developer being aware of this. I'd rather implement check on
>> autobuilder side to insure that packages are optified. Developer can
>> use option XS-Maemo-Optify: none to disable optification if developer
>> doesn't want it.
>
> 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. It potentially can create repository mess
again. And I really don't want this to happen.

> 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.
>
> If it makes you happier: rename the autobuilder as "autobuilder and optifier"!
>
No, it won't make me happier.

> We did agree that there had to be a way for developers to generate packages in
> the scratchbox environment which had been optified in exactly the same way
> the autobuilder would.  And that we would update the wiki pages about
> checking packages will build to include using that tool to test the
> optification.
>
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.

> So, the consensus decision was that the solution would be that autobuilder
> should automatically optify by default.
>
I didn't even think it will go this way. This why I didn't participate
on discussions and BOF, sorry. Does it mean that I should shut up and
do what I'm told to do?

-- 
BR,
Ed
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Reply via email to