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

Re: [Xen-devel] minimum Python version

Jan Beulich writes ("Re: [Xen-devel] minimum Python version"):
> On 20.09.17 at 10:49, <jgross@xxxxxxxx> wrote:
> > What about the following idea: maybe we could add an option to configure
> > to make it fail instead of disabling components in case some
> > requirements for that component are not met? The default could be to
> > just disable the components and with the option specified all components
> > not disabled explicitly must be buildable or configure will fail.
> If that's something that (a) can be reasonably expressed in
> configure.ac and (b) the tools maintainers can live with, that's
> certainly an option.

I'd could live with that.

Personally I think the whole purpose of configure is to allow
automatic building of what's possible, leaving out anything else.

So I think the default for this new option should be to suppress
parts of the build whose dependencies are not satisfied, rather than
to bomb out.

(I wrote "nonessential parts" but I thinkthere are no essential
parts.  The hypervisor itself is already "nonessential" by this
defininion - i386 builds skip it.  And the tools are nonessential
since you might be building on amd64 just for the hypervisor...)

And, yes, configure can express that.  It is an m4-generated shell

My reservation is that this proposed new option would make every
dependency for every feature more complicated.  So to avoid that it
would be necessary to invent new macros to generate the formulaic
enable/disable code.  I doubt anyone has the effort for that.

Jan, I suggest you submit at the very least a patch to change the
minimum to 2.6.  Personally I would accept one to have it disable
python instead of bombing out, if you would like to write it.  That is
the way we deal with many other nonessential components already.

I think that if we want something more sophisticated, involving
optionally bombing out on dependency trouble, it's up to people who
want that to do the work.

(As an aside, I don't think this is a distro/upstream division.  With
my Debian maintainer had on I actually prefer the automatic fallback.
Our build-dependency system avoids accidental creation of broken
packages in normal situations, and having graceful degradation makes
it easier to do unusual things eg in derivatives, when cross-building,
or whatever.)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.