On Wed, Sep 07, 2005 at 12:53:58PM -0600, dann frazier wrote: > On Wed, 2005-09-07 at 18:25 +0200, Sven Luther wrote: > > There is currently no way to solve this short of a rebuild, and only a > > reupload can do this rebuild. > > Well sure - what I'm suggesting (and sounds we all are) is that we make > the upload a direct result of the thing that triggered it, or a single > automated action after the fact. > > This could be done by: > 1) Have linux-2.6 build-dep on all well-behaving kernel-module-source > packages, and have it spit out the module binary debs. > 2) A separate source package that does the above, but avoiding > polution of the already heavyweight linux-2.6 package > 3) The automated build/sign/upload of each individual package. > > And I'm sure others exist.
Isn't using build-deps for that overkill ? Would not simply a database of such package, especially if they are hold in a kernel-module or even the kernel svn repo, be much more easy and efficient for these things ? We could include the automated rebuild of the kernel .udebs in this way too. We slowly bring all the third party module maintainers to work on a extended team, including maintaining always ready module packages in a common svn repo, and once a rebuild is needed, we launch the automated rebuild, and mass sign them as the buildds do. if they break or something they get fixed by hand and use normal rules for building, but we auto or semi-automatically fill FTBFS bugs against the packages. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
