On Mon, Dec 15, 2014 at 10:18:37AM +0700, Michel Alexandre Salim wrote:
>
>
> 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.
FPC would prefer it to be a shared lib ("at least a static library").
The goal of prefering shared libs over copied code is twofold:
1. make it easier to update in case of problems or bugs
2. share the code between running applications in memory
For this specific case 2. does not really apply, because it is unlikely
to have two desktops running at the same time.
For point 1., a static lib has slight advantage over a git submodule.
After a change, after the package containing the static lib it is enough
to rebuild dependent packages. So it *is* slightly less work than replacing
the submodule in the sources, but not too much. Because of this, I
don't see too much virtue in making it a static lib.
> 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.
I'm not sure if the library being static means anything for API guarantees.
Let's say that gvc is updated (incompatibly) and gnome upstream starts
requiring this newer version. If the gvc static lib is updated, other
consumers of the library cannot be compiled or stop working after a
recompilation. If the library is shared, things fail in the same way
either during compilation or at runtime.
> 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.
Zbyszek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
