[Bug 459088] Review Request: protobuf - Protocol Buffers - Google's data interchange format

Tue Nov 11 13:54:33 UTC 2008

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=459088

--- Comment #28 from Lev Shamardin <shamardin at gmail.com>  2008-11-11 08:54:30 EDT ---
(In reply to comment #25)
> Unless you provide the concrete case for this package I strongly
> disagree (packaging guidelines say that the "compelling reason"
> must be provided)
> (If you still want I probably have to ask for FESCo:
> https://fedoraproject.org/wiki/Packaging/Guidelines#Staticly_Linking_Executables
> )

The link above prohibits static linking of executables, and I
completely agree with this policy. But I don't understand how does
this prohibit providing -static library packages without any
statically linked executables.

> > and for these cases having
> > static libraries packaged saves you from rebuilding the required
> > libraries yourself. 
> 
> This is exactly why we think we must _not_ provide static archives unless
> avoided.
> Using static archives will cause problem when some security
> issues or so are found in protobuf and people forget that they are
> using old static protobuf archive, for example.

Are we supposed to fix all potential security issues in the universe?
Potential security issues in fedora packages are effectively handled
in this case with the policy of prohibiting static linking of
*executables*, because in this case the number of statically linked
packages in fedora is minimal. But if the local administrator decides
to build something locally against a -static library, he surely has a
Reason to do this, and he has to perform some additional non-standard
steps to do this (install -static subpackage), and of course he
understands the drawbacks. If I want to make a statically linked
executable for my local system not providing a -static subpackage just
adds some additional inconvenience for me, but will never stop from
static linkage, because I will simply build the static library myself.

To summarize, there are no statically linked *executables* in
protobuf-* packages, so I think that the policy is fulfilled.

> 
> > > !!For -vim subpackage
> > >   ! Neither of %_datadir/vim/vimfiles/{ftdetect,syntax} are owned
> > >     by any packages, however I will ask vim maintainer about this.
> > > 
> > 
> > Any news on this item?
> Oops, completely forgotton, I will surely ask later...
> 
> > > ------------------------------------------------------
> > > Additional remark about python subpackage:
> > > The -python subpackage should not depend on the base package or any other
> > > packages because it is a pure python implementation.
> > > ------------------------------------------------------
> > >     - Well, for technical discussion, does this mean that there will
> > >       be no problem even if the installed version of protobuf and
> > >       protobuf-python differ? (if you don't write Requires this
> > >       can happen).
> > >       This discussion can be applied for -java subpackage.
> > 
> > From my point of view, the only possible problem is that someone can
> > finish using newer protobuf-compiler with older python/java
> > bindings. Both java and python implementations are usable as a runtime
> > without any C++ code, you only need corresponding version of
> > protobuf-compiler for development.
> 
> Then you should ensure that the trouble you mentioned here won't happen.
> * One method is to make -compiler subpackage have:
> -----------------------------------------------------
> Conflicts: %{name}-java < %{version}
> Conflicts: %{name}-java > %{version}
> -----------------------------------------------------
> or so.

I've added 
Conflicts: %{name}-compiler > %{version}
Conflicts: %{name}-compiler < %{version}
to -java and -python subpackages.

(In reply to comment #26)
> Well, for -2:
> 
> * License
>   - Well protobuf.pc.in is still under ASL 2.0
>     You should ask the author to change the license
>     of this file

I removed the license header from the file, leaving only Copyright
notice, as the author suggested.

> * BuildRequires
>   - This package won't build without 
>     "BuildRequires: python-setuptools-devel" (note: here
>     I don't say about Requires).

Fixed. However this is strange, since it did build successfully in
mock on my Fedora 8 system.

> 
> * Requires
>   - "Requires: %{name}-java-%{version}-%{release}" should be
>     "Requires: %{name}-java = %{version}-%{release}"

Fixed.

> 
> * rpmlint issue
> ** non-standard-group
>   - Group "Development/Documentation" should simply be
>     "Documentation".

Fixed.

> 
> ** non-executable-script
> ------------------------------------------------------------
> E: non-executable-script
> /usr/lib/python2.5/site-packages/google/protobuf/descriptor_pb2.py 0644
> ------------------------------------------------------------
>    - If this script are not meant to be executed by user directly,
>      then this script must not have shebang (anyway the shebang
>      #!/usr/bin/python2.4 is wrong because we use python 2.5)

This was in the protoc-generated code. It should be properly fixed in
the upstream code, I've submitted a bug report:
http://code.google.com/p/protobuf/issues/detail?id=56

Meanwhile, I've modified the %build step to fix this.

I've finally converted this package to use gtest library.

Updated SPEC: http://shamardin.googlepages.com/protobuf.spec
New SRPM: http://shamardin.googlepages.com/protobuf-2.0.2-3.fc8.src.rpm

* Tue Nov 11 2008 Lev Shamardin <shamardin at gmail.com> - 2.0.2-3
- Added conflicts to java and python subpackages to prevent using with
  wrong compiler versions.
- Fixed license.
- Fixed BuildRequires for -python subpackage.
- Fixed Requires and Group for -javadoc subpackage.
- Fixed Requires for -devel subpackage.
- Fixed issue with wrong shebang in descriptor_pb2.py.
- Specify build options via --with/--without.
- Use Fedora-packaged gtest library instead of a bundled one by
  default (optional).

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.