Kamil Dudka (kdu...@redhat.com) 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. 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. Bill -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
