Re: Bootstrappable Debian - proposal of needed changes
+++ Wouter Verhelst [2013-01-17 08:33 +0100]:
> However, to do that, there's one thing I'm missing in your mail: there
> will be cases where packages, when built in a particular profile do not
> support some functionality. That is, the package is available and does
> most of what the full package does, but because some build-dependency is
> missing, it doesn't support some feature or other -- for example, let's
> say that a document translation package (which we'll call "foo") which
> supports many input formats does not support XML as an input format when
> built in the stage1 profile. The output of its stage1 build would not
> change the number of binary packages built with the source package, it
> would just build a binary package with reduced functionality.
>
> Now it might be that a package build-depends on our package foo because
> it needs to translate documents in that XML format into something else,
> With your proposal, there's no way for the build-depending package to
> declare that it needs a version of foo that was built at a richer
> profile than stage1.
>
> Is this something you've considered?
Yes. This is unavoidable, and not something that can be dealt with by
extra fields or syntax. This is just 'making software work', and why
'staged/bootstrap' builds are not suitable for the normal archive. We
have to deal with individual cases of problems as they arise, and the
whole process will always be a bit fragile because 'everything' has to
work to get enough packages for a debootstrap out the end. For this
reason if we want to keep it working then a buildd running regular
bootstraps is the only way to know that things are still in a useable
state.
Remember that for cyclic build-dependency loop-breaking there are not
that many loops to break: I found about 30 IIRC, many just pairs of
(source) packages, plus one big gnarly set) and thus a fairly limited
set of packages that need to be touched (johannes says no more than
83, the actual number being refined right now). In practice we've not
hit anything unexpected like this because the things we dropped really
are optional (libselinux support in eglibc, java bindings in libdb,
ldap support in kerberos, ruby bindings in libselinux,
object-introspection (simply skipping this will cause an issue at some
point - it needs crossifying))
Also remember that document-processy things are often MA:foreign which
also means the sort of problem in your example is relatively unlikely.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: