On Friday 18 March 2016 05:14:28 Nico Kadel-Garcia wrote:
> On Fri, Mar 18, 2016 at 4:29 AM, Petr Pisar <ppi...@redhat.com> wrote:
> > I think the solution is have more packages delivering the same-named
> > shared library file with the same soname. Each of the packages
> > conflicting each other. Then the non-minimal package would provide RPM
> > symbols declaring compiled-in features like "Provides: libcurl(LDAP)"
> > and then each application package requiring specific feature would
> > explicitly run-require it ("Requied: libcurl(LDAP)"), besides
> > automatically genererated dependency on the soname.
>
> I suspect the better solution is to stop burning effort rewriting the
> structure of core utilities for something that does not actually
> improve the utility
Exactly. That is why I am not proposing a crazy plug-in system
for libcurl :-)
> , but only helps with edge cases, in this case in
> minimalizing build environments.
Neither me, nor Petr were talking about minimalizing build environments.
> This is extremely difficult to test,
Really? What exactly were the problems you encountered while you
were testing the curl-minimal and libcurl-minimal packages?
Kamil
> and as likely to cause fracturing of unexpected test environments as
> the reduced versions of "parted" caused in anaconda years ago.
>
> > The magic of prefering the minimal package over non-minimal package
> > would be kept on package manager. For example it could sort the
> > candidates on size or number of dependencies.
>
> Maintaining it is likely to break the ability to test expected
> features when compiling in userland, then expect them to work the same
> way in mock or koji at build time.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
