[Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)

[Michel Alexandre Salim]

On 12/13/2014 12:54 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Dec 12, 2014 at 09:38:52AM -0500, Bastien Nocera wrote:
>>
>>
>> ----- Original Message -----
>>> On 12/12/2014 03:18 PM, Bastien Nocera wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> On Fri, Dec 12, 2014 at 09:04:19AM -0500, Bastien Nocera wrote:
>>>
>>>>> Agreed, a static library is a waste of time. What about a normal
>>>>> shared library? Do you think patches to do that would be accepted?
>>>>
>>>> How does a shared library solve any of those problems?
>>> I wonder why I have to explain this ;)
>>>
>>> It would concentrate/centralize a distributed, undetectable origin of
>>> bug into one point of maintenance and development.
>>
>> It wouldn't solve the problem of not wanting to offer an API to third-parties...
> Hi,
> 
> I understand why upstream did not want to do that, but current
> situation is not very attractive either. The same piece of library-like
> code is duplicated in two places in gnome, in cinnamon, and we are talking
> about duplicating in a fourth place.
> 
> FPC wants to have it split out and shared. gvc has the last commmit in
> git 13 months ago. Shouldn't be that much of an issue to split it out.
> 
Having a static lib that goes against upstream's wishes, and that won't
be used by the core GNOME applications anyway, seems rather anomalous as
well.

On the other hand, given that Cinnamon, Budgie, and other GNOME-related
external projects are using this internal dependency anyway, I'd say the
intent of not offering an API to third-parties has already failed... and
not offering a *stable* API should be obvious enough by offering only a
static lib. We could even add a README.Fedora file clearly stating that
this library comes with no API stability guarantee.

Seems that we should go back to the FPC, now that the objection from
upstream (in some cases overlapping with Fedora package maintainers) is
clear. At the very least, we need a decision on what to do with shared
internal modules that are not intended to be used by external third
parties - like libgd and libg-v-c, but I won't be surprised if there are
others.

- is the current practice acceptable, or (per last week's FPC decision)
should the use of a static lib be required
- once such a static lib is made available, is its use optional or
mandatory for existing / new packages, and what's the timeline for
requiring dependent packages to build against it
- or should we have a two-tier policy, with, say, modules from the
originating project allowed to pull in such dependencies via git
submodules as per the current practice, but external modules required to
use the static lib?

With the latter, in the case that, say, individual GNOME modules need to
be built against different commits of such a shared dependency, they
still can, while we at least have centralized such dependency's usage by
external projects.

Best regards,

-
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  salimma at fedoraproject.org  | GPG key ID: A36A937A
IDs:    keybase.io/michel-slm      | IRC: michel_slm at irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20141215/1ea189ca/attachment.sig>