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

[bugzilla at redhat.com]

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 #25 from Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>  2008-11-01 09:22:35 EDT ---
(In reply to comment #23)
> (In reply to comment #21)
> > * Shipping -static subpackage
> >   - Please explain why this package is needed where -devel
> >     subpackage is provided which includes .so symlink libraries.
> >     Usually static archives must be removed unless
> >     the package does not provide shared libraries.
> 
> There are
> some cases when you need static libraries, 

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
)

> 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.

> > !!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.

> >   * For -java subpackage
> >     - About "BuildRequires: java-devel >= 1.6.0"
> >       -- If this means that Java binding needs OpenJDK to
> >          build, then this line must be
> > --------------------------------------------------------
> > BuildRequires: java-devel >= 1:1.6.0
> > --------------------------------------------------------
> >          java-devel vitrual Provides by java-1.6.0-openjdk-devel
> >          has Epoch 1 for historical reason (see:
> 

> I can successfully build the package with
> java-1.6.0-sun-devel-1.6.0.3-1jpp without mock on my system, and
> BuildRequires: java-devel >= 1.6 brings
> java-1.7.0-icedtea-devel-1.7.0.0-0.19.b21.snapshot.fc8.i586 which
> builds the package succesfully.

Well, actually I don't care about RHEL4, however for this case
I can allow "java-devel > 1.6".

-- 
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.