proposal to remove static libs from -devel packages for FC5
Daniel Veillard
veillard at redhat.com
Thu Jul 28 11:05:39 UTC 2005
On Fri, Jul 22, 2005 at 08:08:17PM -1000, Warren Togami wrote:
> >So they should just be removed. Some packages may have a --disable-static
> >configure option for example to help with this, or they can just be
> >deleted easily by hand in the %install section.
> >
> >For the cases where it is still desirable or necessary to ship static libs,
> >I would suggest to move them from -devel into a separate -static
> >subpackage so that people who don't need them don't have to suffer
> >downloading and installing them.
> >
> >Does this sound reasonable? Make any sense? :)
I dislike that. Any non-LSB lib should have static libs available one way
or another from the distro otherwise we just make the distro unsuitable for
ISV development (from an LSB POV). Now having a duplicate for -devel in -static
1/ breaks all the documentation and user expectations
2/ forces Fedora Core 5 spec to be different from other distro specs
Just taking the example of libxml2 upstream maintainer viewpoint this means:
1/ that I need to change my FAQ and user documentation to say that
if you use Fedora Core X X>5 and you need static link, then user should
also install libxml2-static and it must also be in the same rpm
transaction as the main, devel and python packages otherwise this
may just fail.
2/ that I either have to change my upstream packaging model, as I ship RPM
and maintain my upstream and Fedora/RedHat spec in sync, or I must have
different spec for upstream and Fedora which IMHO is a bad regression
(and yes at least one other distro at least test the same spec file:
Mandriva)
Now multiply by the number of library we ship, to me you annoy the user
and the maintainers.
I really disagree with this myself.
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
More information about the Fedora-maintainers
mailing list