Proposal to reduce anti-bundling requirements

[Zdenek Kabelac]

Dne 11.9.2015 v 15:21 Neal Gompa napsal(a):
> On Fri, Sep 11, 2015 at 9:03 AM, Zdenek Kabelac <zkabelac at redhat.com
> <mailto:zkabelac at redhat.com>>wrote:
>
>     Dne 11.9.2015 v 14:46 Germano Massullo napsal(a):
>
>         I have read the whole discussion and I would like to share my opinion,
>         even if I think it could be a bit off-topic.
>         Given that Fedora community alone, cannot educate every upstream
>         developer about unbundling, and considering that it is a problem that
>         interests all main Linux distributions: I think that Fedora community
>         could (and should) propose to other Linux distribution communities to
>         make a general effort to kindly ask upstream devs to reconsider their
>         work, enforcing unbundling.
>         This will take years, but I think it is a way we should cover.
>
>
>     How Fedora wants to educate 'upstream' when it rather fails on many levels
>     when we talk about library handling.
>
>     Fault #1
>
>     Fedora badly supports multiple libraries of different version - i.e.
>     typically full rebuild of whole repo is made when new library is
>     introduced - which is typically quite bad idea (and this is not just
>     because of simple version change requires reload of many GB of packages)
>     (I've already complained that usage of rawhide & rpmfusion is getting silly)
>
>
>
>     Fault #2
>
>     Version of libraries is wrongly handled on packaging level as well as on
>     build level and many library packages are not correctly versioned - so if
>     someone believe there is some use of  libname.so.major.minor.patch - for
>     RPM it's mostly useless and if symbols are not properly version inside
>     library, dependency will simply not work -  and just adding 'constant'
>     version string to every symbol inside library will not make this work
>
>     Zdenek
>
>
> ​I get the feeling this is related to Fedora not aggressively using versioned
> package names for libraries, or at least enabling some kind parallel
> installing capability. SUSE used to follow a policy similar to our current
> one, but switched due to the insanity and impracticality. Mageia also uses a
> policy almost identical to SUSE's.
>
> For an example, here's SUSE's policy:
> https://en.opensuse.org/openSUSE:Shared_library_packaging_policy​
>
> ​I've been meaning to ask about why we don't do this for a while now, but it
> seems like now is a good of a time as any...​


I found the idea of making packages purely dependent on versioned symbols as 
not so ideal plan either - as this way you will not  be able handle any new 
flags supported by libraries which uses still same symbols -  UNLESS you 
expected developer to be 'versioning'-fanatic - to maintain versioning of 
symbols at low-level and update 'version' for every tiny upgrade he does for a 
symbol -  how many packages  does that ??
(i.e. your existing API function will handle new 'enum flag' - change its 
version string)

So while 'versioned' symbols do have some logic - it still should not be 
forgotten that  RPM should rather put in  package dependency on the library 
being at least as good as the one used for compilation. Depending purely on 
provided 'symbols' is not exactly what one would expect....

Zdenek