On Thu, Mar 17, 2016 at 11:55 AM, Bill Nottingham <nott...@splat.cc> wrote: > 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.
- Fedora Modularity Objective (creating a small Base and building out Editions or $cool_things by using modules on top of it) Now, none of the above goals require the curl work Kamil has done, but it does play a positive in almost all of them if it can be accomplished in a suitable manner. josh -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
