On Thursday 17 March 2016 11:55:31 Bill Nottingham wrote: > Kamil Dudka (kdudka@xxxxxxxxxx) said: > > > If you care about a consistent developer, user, and debugging experience > > > regardless of mechanism of delivery, you wouldn't do this in the first > > > place, or you'd change the global curl package. Either the features are > > > important, or they aren't. > > > > Are you implying that curl maintainers know better than users which > > features are important for the users themselves? > > ... well, that's sort of what turning off features for this case implies. > > > > If you care about minimizing size overall (neglecting the fact that > > > cutting out kerberos and to a lesser extent ldap dependencies don't > > > really > > > save you anything due to their system library use), then might as well > > > just > > > start -Os-ing random packages and throwing in busybox. > > > > Micro-optimization is way to hell. The system needs to optimized by > > design. > EXACTLY! Maybe I'm not being clear in what I'm trying to say, but this is > the point - it needs to be designed. > > 1) Start with the design of who are we targeting - what jobs are then trying > to do? > > 2) Then, what do we produce? (Atomic, Server, Cloud, Workstation) > > 3) Do they have different needs? Do we build components with different > features for each? (This solution implies 'yes', but I don't recall seeing > that stated before) > > 4) If so, what are the differentiating features that require different > components with different feature sets? What's the job that someone is > trying to do that requires this? (The impliciation is 'download the base > image somewhat faster', but that's still very vague.) > > 5) Then, pick the targeted points and propose implementation of individual > features that serve the larger goal. The motivation behind this effort is pretty straightforward. I have been maintaining curl in Fedora/RHEL since 2009. From time to time users ask me to reduce the number of run-time dependencies of (lib)curl. At the same time, users are continuously requesting to add new features to Fedora (lib)curl and this introduces additional run-time dependencies. The last request, which actually triggered this effort, was adding the support for libpsl, which itself requires libicu and libstdc++: https://bugzilla.redhat.com/1305701#c1 I wanted to provide a solution to the continuously growing list of (lib)curl run-time dependencies. Having two builds of the same source code that just differ in their build-time configuration sounded like a good trade-off from the perspective of a maintainer: - one suitable for the users that request adding new features - one suitable for the users that request reducing the run-time dependencies I am open to discuss what features should be included in (lib)curl-minimal and I already refined my draft base on the discussion in this thread. I am also open to discuss other solution to the above problem. The other proposals I have captured in this thread are: - use dlopen() -- already proven wrong (see RHBZ and upstream ML) - use static linking -- sub-optimal due to high security advisory rate - multiple libcurl DSOs on a system -- problematic (see RHBZ and upstream ML) - tweak dnf to use libcurl-minimal if installed in parallel to libcurl -- not a generic enough solution for me to consider (as it would work for dnf only) > It's possible that, just poking my head up, I missed all the 1-4 discussion > that this is tied to. But given that the following has all popped up in > the past few months: > > - "Minimizing the fedora docker base image footprint" (by yanking dnf et.al. > into a seprate container, making size of it much more irrelevant) - "DNF > into C initiative started" (enabling a much larger depythoning that doesn't > require differing library buidls) > - "F24 Self Contained Change: System Python" > > ... the fact that we now have four separate implementation details, all of > which could make different parts of the others irrelevant, makes me wonder > about the design behind it. So what exactly are you proposing? Kamil > Bill -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
