2009/10/29 Andrew Flegg <and...@bleb.org>: > Ed wrote: >> 2009/10/29 Graham Cobb <g+...@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 _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
