2009/10/28 Andrew Flegg <and...@bleb.org>: > Ed wrote: >> > >> > I've put together a suggested spec for the decision, taken at the >> > summit during the /opt BOF[1], that the auto-builder would run some >> > maemo-optify version during the build process (controlled by a control >> > file header): >> >> Sorry, I seem to miss the whole point of this activity. Why do you >> need to do that on autobuilder side? As far as I understood it's just >> a matter of including maemo-optify as a build dependency and run it >> in debian/rules, right? Why developer can't do this then? I don't see >> much difference between setting XS-Maemo-Optify and changes I >> mentioned above. In both cases developer should understand what >> optification means. > > The consensus at the BOF was that since it's something which SHOULD be done > for all Maemo packages, but that this is Maemo specific, that it should be > done at the autobuilder to ensure that as many packages are optified as > possible. > > By having "auto" be the default (i.e. the developer has NOT specified > XS-Maemo-Optify) at some point in the future we can avoid the current problem > where, even though the requirements are well understood more than half the > user-facing applications in -testing aren't using /opt. >
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. Explicit is better than implicit. (C) Zen of Python :) -- BR, Ed _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
