[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Getting the buildds to notice new architectures in a package

Wouter Verhelst <wouter@debian.org> writes:

> On Mon, Jul 17, 2006 at 02:40:28PM -0400, Joe Smith wrote:
>> "Wouter Verhelst" <wouter@debian.org> wrote in message 
>> >There is no such general solution. See
>> ><http://www.debian.org/devel/buildd/wanna-build-states#not-for-us>
>> That says:
>> >However, wanna-build does not look at the control file of a package
>> >when creating its database; only at the packages' name and section,
>> >its urgency, and its priority.
>> Shouldn't wanna-build use the control file?
> Perhaps. The issue is that wanna-build needs to know whether a package
> has already been built for its architecture; one can only find that out
> by looking at the Packages file, and comparing that with the Sources
> file.
> Since the Packages and Sources files contain all the information
> wanna-build needs (except for the architectures for which a build should
> be attempted), and since fetching the control files is a _lot_ more work
> than to write a parser for Packages and Sources files which can just be
> piped into wanna-build, it isn't done.
> Also, such a thing would probably require quite some I/O, so I'm not
> entirely sure it's worth it. But if you could write some patch which
> does not ever break and which allows to read the control file, I'm sure
> it'll be welcome.
> (I'm not sure why it still listed "upload urgency" as a criterion there
> -- that's a bug in the documentation that I introduced, but it's never
> been true. I've just committed a fix)
>> It would then mean that the lists of packages-arch-specific would not
>> be needed, except in the case of a single version override in the
>> event that a package's control file accidentally listed an
>> architecture on which it is not supported, or failed to list an
>> architecture on which it is supported. 
> The latter wouldn't work anyway -- if it isn't supported,
> dpkg-buildpackage refuses to build the package.

Two things:

- control files are part of the source. w-b would have to download and
unpack every source package to get that file.

- control files can be auto generated during build (e.g. glibc) and
might not even list the packages and architectures

If you want to get rid of the P-a-s file then I suggest you work on
fixing the Architecture field in the Sources file to truely reflect
the architectures the source should be build for. What you have to
worry about is the case of architecture specific sources that also
have architecture independent packages. In those cases the
Architecture field lists "any" instead of e.g. "i386 amd64 all".

If you fix that and allow sources to override the Architecture field
(for autogenerated control files like glibc) then the Sources.gz file
would have all the right information in the normal case. This would
cut down the P-a-s list seriously.


Reply to: