On Tue, Dec 21, 2010, Andreas Barth wrote: > The question is also if we accept all these limitations as sane for > bootstraping: > 1. some binary packages might be not built > 2. documentation might be missing > 3. user interface might restricted (e.g. a package might be compiled > without readline) > > 1. and 2. seems fairly obvious to me, but question is if we accept the > third limitation (for me, it sounds ok, as long as the limitation > doesn't make other packages FTBFS).
Yes; it's really the key problem in bootstrapping; I would think that an acceptable compromise is if an intermediate stage of a source package provides only a subset of the binary packages, or perhaps a different set of binary packages. For instance, if src:foo usually produces libfoo, libfoo-dev and python-foo, it would be ok to provide only libfoo and libfoo-dev as part of the first stage iif the first stage libfoo doesn't break any package. If libfoo is built with different flags in the first stage and that breaks any rdeps (or rbdeps), then the first stage should provide a different package name e.g. libfoo-stage1, or libfoo-noreadline and relevant rdeps/rbdeps should be adapted to cope with this. In this way, we reduce the interface (dependencies) between packages to the package name alone and we don't need to check whether the package has a particular feature or was built in a particular stage. -- Loïc Minier -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
