8:21 p.m.
Dear developers,
On 12/12/2014 01:27 AM, James Antill wrote:
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 17:01:37 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-12-11/fpc.2014-12-...
.
Meeting summary
---------------
* Roll Call (geppetto, 17:01:37)
* #476 Requesting copylib exemption for libgnome-volume-control
(geppetto, 17:06:19)
* ACTION: General agreement that it should be made at least a static
lib. … hopefully a shared lib. eventually. (geppetto, 17:20:11)
Per the FPC decision that libgnome-volume-control is not an acceptable
copylib, and therefore it has to be packaged as a static lib and
packages using it modified to use it, some questions:
1. who should be performing the modification?
2. presumably reviews of new packages depending on this would be blocked
until such a static lib is available?
3. presumably whereas legacy packages that have already gone in are
fine, we won't want to yank them
Best regards,
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A
IDs: keybase.io/michel-slm | IRC: michel_slm(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
3:25 a.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
----- Original Message -----
Dear developers,
On 12/12/2014 01:27 AM, James Antill wrote:
> ======================
> #fedora-meeting-1: fpc
> ======================
>
>
> Meeting started by geppetto at 17:01:37 UTC. The full logs are available
> at
>
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-12-11/fpc.2014-12-...
> .
>
>
>
> Meeting summary
> ---------------
> * Roll Call (geppetto, 17:01:37)
>
> * #476 Requesting copylib exemption for libgnome-volume-control
> (geppetto, 17:06:19)
> * ACTION: General agreement that it should be made at least a static
> lib. … hopefully a shared lib. eventually. (geppetto, 17:20:11)
>
Per the FPC decision that libgnome-volume-control is not an acceptable
copylib, and therefore it has to be packaged as a static lib and
packages using it modified to use it, some questions:
1. who should be performing the modification?
2. presumably reviews of new packages depending on this would be blocked
until such a static lib is available?
3. presumably whereas legacy packages that have already gone in are
fine, we won't want to yank them
That won't happen.
Cheers
3:29 a.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
Hi Bastien,
On 12/12/2014 04:25 PM, Bastien Nocera wrote:
>> Meeting summary
>> ---------------
>> * Roll Call (geppetto, 17:01:37)
>>
>> * #476 Requesting copylib exemption for libgnome-volume-control
>> (geppetto, 17:06:19)
>> * ACTION: General agreement that it should be made at least a static
>> lib. … hopefully a shared lib. eventually. (geppetto, 17:20:11)
>>
> Per the FPC decision that libgnome-volume-control is not an acceptable
> copylib, and therefore it has to be packaged as a static lib and
> packages using it modified to use it, some questions:
>
> 1. who should be performing the modification?
> 2. presumably reviews of new packages depending on this would be blocked
> until such a static lib is available?
> 3. presumably whereas legacy packages that have already gone in are
> fine, we won't want to yank them
That won't happen.
Presumably you're refering to #3 here? Or you're saying there won't be
a
libgnome-volume-control static lib?
Thanks,
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A
IDs: keybase.io/michel-slm | IRC: michel_slm(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
8:04 a.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
----- Original Message -----
Hi Bastien,
On 12/12/2014 04:25 PM, Bastien Nocera wrote:
>>> Meeting summary
>>> ---------------
>>> * Roll Call (geppetto, 17:01:37)
>>>
>>> * #476 Requesting copylib exemption for libgnome-volume-control
>>> (geppetto, 17:06:19)
>>> * ACTION: General agreement that it should be made at least a static
>>> lib. … hopefully a shared lib. eventually. (geppetto, 17:20:11)
>>>
>> Per the FPC decision that libgnome-volume-control is not an acceptable
>> copylib, and therefore it has to be packaged as a static lib and
>> packages using it modified to use it, some questions:
>>
>> 1. who should be performing the modification?
>> 2. presumably reviews of new packages depending on this would be blocked
>> until such a static lib is available?
>> 3. presumably whereas legacy packages that have already gone in are
>> fine, we won't want to yank them
>
> That won't happen.
>
Presumably you're refering to #3 here? Or you're saying there won't be a
libgnome-volume-control static lib?
The whole goal of using a git submodule is so that we don't offer to 3rd-parties
a library, and so that we can change the API without any problems. Using a static
library offers all the disadvantages and none of the advantages of using a git submodule.
So it won't be changed upstream, or downstream.
I'm guessing the FPC hasn't found out about the libgd git-submodule yet...
8:09 a.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
On Fri, Dec 12, 2014 at 09:04:19AM -0500, Bastien Nocera wrote:
> On 12/12/2014 04:25 PM, Bastien Nocera wrote:
> >>> Meeting summary
> >>> ---------------
> >>> * Roll Call (geppetto, 17:01:37)
> >>>
> >>> * #476 Requesting copylib exemption for libgnome-volume-control
> >>> (geppetto, 17:06:19)
> >>> * ACTION: General agreement that it should be made at least a static
> >>> lib. … hopefully a shared lib. eventually. (geppetto, 17:20:11)
> >>>
> >> Per the FPC decision that libgnome-volume-control is not an acceptable
> >> copylib, and therefore it has to be packaged as a static lib and
> >> packages using it modified to use it, some questions:
> >>
> >> 1. who should be performing the modification?
> >> 2. presumably reviews of new packages depending on this would be blocked
> >> until such a static lib is available?
> >> 3. presumably whereas legacy packages that have already gone in are
> >> fine, we won't want to yank them
> >
> > That won't happen.
> >
> Presumably you're refering to #3 here? Or you're saying there won't be
a
> libgnome-volume-control static lib?
The whole goal of using a git submodule is so that we don't offer to 3rd-parties
a library, and so that we can change the API without any problems. Using a static
library offers all the disadvantages and none of the advantages of using a git submodule.
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?
Zbyszek
8:18 a.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
----- Original Message -----
On Fri, Dec 12, 2014 at 09:04:19AM -0500, Bastien Nocera wrote:
> > On 12/12/2014 04:25 PM, Bastien Nocera wrote:
> > >>> Meeting summary
> > >>> ---------------
> > >>> * Roll Call (geppetto, 17:01:37)
> > >>>
> > >>> * #476 Requesting copylib exemption for libgnome-volume-control
> > >>> (geppetto, 17:06:19)
> > >>> * ACTION: General agreement that it should be made at least a
> > >>> static
> > >>> lib. … hopefully a shared lib. eventually. (geppetto,
17:20:11)
> > >>>
> > >> Per the FPC decision that libgnome-volume-control is not an
acceptable
> > >> copylib, and therefore it has to be packaged as a static lib and
> > >> packages using it modified to use it, some questions:
> > >>
> > >> 1. who should be performing the modification?
> > >> 2. presumably reviews of new packages depending on this would be
> > >> blocked
> > >> until such a static lib is available?
> > >> 3. presumably whereas legacy packages that have already gone in are
> > >> fine, we won't want to yank them
> > >
> > > That won't happen.
> > >
> > Presumably you're refering to #3 here? Or you're saying there won't
be a
> > libgnome-volume-control static lib?
>
> The whole goal of using a git submodule is so that we don't offer to
> 3rd-parties
> a library, and so that we can change the API without any problems. Using a
> static
> library offers all the disadvantages and none of the advantages of using a
> git submodule.
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?
8:33 a.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
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.
Ralf
8:38 a.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
----- 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...
11:54 a.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
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.
Zbyszek
9:18 p.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
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(a)fedoraproject.org | GPG key ID: A36A937A
IDs: keybase.io/michel-slm | IRC: michel_slm(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
8:09 p.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
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
9:33 a.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
On Mon, 2014-12-15 at 10:18 +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.
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.
I don't think you can really force a package maintainer to provide a
static library for code the is very explicitly not meant to be shared.
Just because others decided to ignore that wish and copied it anyway.
The only outcomes I can see if this is being forced is a) us loosing
package maintainers who are fed up with this or b) upstream starting to
change internal apis every release, just to make copying this code so
difficult that it becomes impractical.
5:35 a.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
On Tuesday, 16 December 2014 at 16:33, Matthias Clasen wrote:
I don't think you can really force a package maintainer to
provide a
static library for code the is very explicitly not meant to be shared.
Just because others decided to ignore that wish and copied it anyway.
The only outcomes I can see if this is being forced is a) us loosing
package maintainers who are fed up with this or b) upstream starting to
change internal apis every release, just to make copying this code so
difficult that it becomes impractical.
In this sad case, the solution is to request a copylib exception from
the FPC covering this and other "not meant to be shared" libraries.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
12:49 p.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
On 12/12/2014 07:04 AM, Bastien Nocera wrote:
I'm guessing the FPC hasn't found out about the libgd git-submodule yet...
Apparently not as I don't see any FPC tickets for it nor listed here:
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gra...
gnome-music at least has:
# libgd is not meant to be installed as a system-wide shared library.
# It is just a way for GNOME applications to share widgets and other common
# code on an ad-hoc basis.
Provides: bundled(libgd)
but there should have been an FPC ticket filed. Unfortunately not picked up
in review: https://bugzilla.redhat.com/show_bug.cgi?id=999268
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
6:56 p.m.
New subject: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
Bastien Nocera wrote:
So it won't be changed upstream, or downstream.
It MUST be changed downstream according to our policies. If you refuse to do
it, then you should get removed from that package's Fedora maintainership.
Sometimes, it's better to have a packager who's not also an upstream
developer, in order to resolve this kind of conflicts of interest.
Kevin Kofler
3444
days inactive
3449
days old
14 comments
8 participants
participants (8)
-
Bastien Nocera -
Dominik 'Rathann' Mierzejewski -
Kevin Kofler -
Matthias Clasen -
Michel Alexandre Salim -
Orion Poplawski -
Ralf Corsepius -
Zbigniew Jędrzejewski-Szmek