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

Re: debian-xcontrol updated



Hi,

On Wed, May 06, 2009 at 02:21:58PM +0100, Neil Williams wrote:

> >  - "Optional": This package is not built by the regular build target.
> > There needs to be a policy how to build these packages, my suggestion
> > would be "build-<packagename>" and "binary-<packagename>" targets.
> > This allows e.g. toolchain packages to list the cross variants in the
> > xcontrol file so an xcontrol aware autobuilder can see them and
> > specifically request them to be built. This is per-binary, defaults
> > to "no".

> Useful for the CodeAudit and regular packages too. It will provide a way
> to encode things like libgconf-noldap-2-4 etc.

Another interesting use case would be cross compilers -- we could add these
as optional binary packages to the regular compiler source packages, and
the Debian autobuilder would ignore them.

> >  - "Cross-Compiling": This package supports cross-compilation in the
> >    build-arch/binary-arch targets. Can be set globally for the source
> >    package and overridden in the binary package stanzas. Defaults to
> > "no".

> Every debian/xcontrol file created by patches for emdebian-tools will
> gain this support as part of the CodeAudit and those changes fed into
> the mass bug filing in the Debian packages. Skipping certain packages
> entirely is very useful but I'm not sure how to implement support for
> that.

I think I'll add a check that there are no non-optional packages declaring
lack of crossbuilding support when the source section says "yes".

It could also be used in audit progress tracking -- "yes", "no" or absent.

> emdebian-tools will probably "switch-on" packages that are "Optional"
> && "Cross-Compiling: yes".

I haven't thought about how to define a (vendor?) policy yet. "Optional" is
more about the technical possibility that this package may be built
separately from the others (which can be used to find alternate paths in
the dependency tree if one path is blocked by policy). As an example:

 - dependency path: libc - libldap - libgconf - gdm
 - autobuilder policy: blacklist libldap
 - libgconf cannot be built regularly, because a non-optional package
   declares a build-dependency on libldap (note that this build-dep is in
   the package section, not the source section, which still allows optional
   packages to have looser dependencies than non-optional ones)
 - the build-dep from gdm to libgconf-dev can be satisfied via an
   alternative "| libgconf-noldap-dev" in the gdm package.
 - the autobuilder decides to build libgconf-noldap-dev
 - gdm can be built regularly because its build-depends can be satisfied
   now

The only thing missing here is how libgconf-noldap-2-4 is built. I could
think of three ways:
 - the -dev package build implicitly builds the library package as well and
   silently adds it to debian/files.
 - the autobuilder looks at the resulting -dev package, sees the broken
   dependency and asks for the library package
 - we add a separate xcontrol field linking these packages together

The last one looks cleanest to me.

The policy you describe "build everything including optional packages as
long as it can be cross-compiled" can be defined external to the packages,
but I'm unsure whether we also need a mechanism ("Vendor:"?) to declare
that a package is not meant to be built for emdebian.

   Simon


Reply to: