Maybe use [email protected] for profile questions in general (even when they affect native building)? I believe all profile people are subscribed there.
On Wed, Aug 26, 2015 at 07:16:26PM +0200, Johannes Schauer wrote: > It indeed uses "filter" as Daniel already pointed out. Yes, please always use filter for testing profiles. Having one canonical way of doing so helps with reading the code later. > > > A difference between using the system libraries vs. the bundled one might > > > be the feature set that curl is built with. Afaik cmake uses curl to > > > submit test results to a dashboard and to allow downloading files during a > > > build. I wouldn't expect differences in curl to impact cmake in the > > > context of Debian package builds. > > > > > > > On the other hand, it would impact user-visible functionality. See for > > example http://www.cmake.org/pipermail/cmake/2014-October/058911.html. So, > > doing this without a rename of the resulting cmake package would technically > > violate the requirement we're discussing. Whether it's a small enough > > violation that it could be ignored, I don't really know. > > > > I'd be fine with adding this to cmake. Please let me know if this would be > > useful. > > I CC-ed Helmut who is currently the best person to know whether making > libcurl*-dev optional for src:cmake makes any sense at all or not. Is this for the native bootstrap? I think cmake should not be part of the cross bootstrap. curl is part of the strong essential set on http://bootstrap.debian.net/essential.html. So you can assume that curl is available in the native bootstrap. In resolving the cross bootstrap manually, I figured that curl is indeed necessary and it will soon show up on rebootstrap[1]. The currently missing parts are cyrus-sasl2, openldap, libverto and krb5. For cyrus-sasl2 I already submitted a patch to make it build at #792851 and for openldap I will be proposing a stage1 that drops slapd. Thus we not only know that curl will be needed, but we also know that building curl without cmake is feasible. I conclude that curl will be available when building cmake (no matter whether native or cross). What was the original need that made you ponder dropping curl? Daniel, can you point out how you bootstrap stuff? I've seen you proposing stages in a number of cases where I thought that none should be necessary. I'm really curious: Maybe I am using too many stages in other places. rebootstrap currently stages glibc, libselinux, util-linux, file, db5.3, libidn, cracklib2 and pam. I am pondering to use stages for cdebconf, newt, libcap-ng, python2.7, cyrus-sasl2, openldap and systemd. Does any of those work without stages for you? Helmut [1] https://wiki.debian.org/HelmutGrohne/rebootstrap
