Re: Meaning of the "Altering package upload rules"
On Sat, Feb 16, 2008 at 02:02:28PM +0100, Bernhard R. Link wrote:
> > Hence I think we should push for source upload. Other technical
> > incentives can then be found and I've already suggested some of them,
> > e.g. tuning our upload tools so that they indeed require the existence
> > of a .deb, not necessarily uploading it later on.
>
> So why don't you start with implementing them first? Building a
> framework for doing unclean builds (a.k.a. buildd from hell), checking
> for missing build-conflicts, tools for comparing different .debs of the
I had in mind to simply use debdiff to compare the deb built by the DD
and the one produced by the buildd. It already spots most relevant
differences, like missing files or different dependencies.
I've to admit I'm a bit ignorant about the way buildds work, especially
the queue mechanism, but my idea was just to schedule the build also on
the i386 buildd (when the DD uploads an i386 package for example) and
still move into the archive the .deb built by the DD. Then, when the
package built by the buildd is ready, instead of moving it blindly to
the archive, check if a file with the same name is there, and in that
case do a debdiff and eventually mail the output to the DD.
> same version and stuff like that can all be implemented without having
> to switch to source-only first and are all worth even if that never
sure, but I thout the changes to implement this idea were 10 lines of
code. I'll try to gather more infos about how build jobs are scheduled
and I'll read the link Aj provided.
Cheers
--
Enrico Tassi
Reply to: