mythes does not create a shared library

Bug #20254 reported by Martin Pitt
4
Affects Status Importance Assigned to Milestone
Ubuntu
Fix Released
High
Matthias Klose

Bug Description

mythes was approved into main under the condition that it gets a shared library
by the breezy release. The current package only builds a static one, which is evil.

Revision history for this message
Matthias Klose (doko) wrote :

Martin, is there a policy that forbids having a library package without having a
shared version of the library?

Revision history for this message
Martin Pitt (pitti) wrote :

(In reply to comment #1)
> Martin, is there a policy that forbids having a library package without having a
> shared version of the library?

Not really a policy, but it is good and common practice. Just yesterday you
could experience the mess of not doing it yourself (fixing a dozen python
packages because it has copies of pcre code). With a static library, a mere
rebuild would be sufficient, but (1) it is still ugly to waste user's bandwiths
and the security team's time with it and (2) it is hard to remember all static
copies in the first place.

Revision history for this message
Matthias Klose (doko) wrote :

(In reply to comment #2)
> Not really a policy, but it is good and common practice. Just yesterday you
> could experience the mess of not doing it yourself (fixing a dozen python
> packages because it has copies of pcre code).

the pcre example is not a good one, as you noticed the heavily modified source.

> With a static library, a mere
> rebuild would be sufficient, but (1) it is still ugly to waste user's bandwiths
> and the security team's time with it and (2) it is hard to remember all static
> copies in the first place.

For (2) we should keep a list of library copies in packages. There are cases,
where the shared library avalailabe cannot or should not be used. This list will
never be empty.

Revision history for this message
Martin Pitt (pitti) wrote :

(In reply to comment #3)
> (In reply to comment #2)
> > Not really a policy, but it is good and common practice. Just yesterday you
> > could experience the mess of not doing it yourself (fixing a dozen python
> > packages because it has copies of pcre code).
>
> the pcre example is not a good one, as you noticed the heavily modified source.

It is a good example that this is a really painful approach and should be avoided.

> > With a static library, a mere
> > rebuild would be sufficient, but (1) it is still ugly to waste user's bandwiths
> > and the security team's time with it and (2) it is hard to remember all static
> > copies in the first place.
>
> For (2) we should keep a list of library copies in packages.

That will be error prone and incomplete since not everybody will always remember
to update that list on every upload.

> There are cases,
> where the shared library avalailabe cannot or should not be used. This list will
> never be empty.

Right, but we should keep it small. Especially in cases where it is just a
matter of an easy package change to build a shared library.

Revision history for this message
Martin Pitt (pitti) wrote :

Building a shared library is straightforward:

  g++ -shared -fPIC mythes.o -o libmythes.so -Wl,-soname -Wl,libmythes.so.0

and add -fPIC to the CXXFLAGS in the Makefile.

Since neither upstream nor Rene seem to care for the soname, we can just leave
it as 0.

Revision history for this message
Matthias Klose (doko) wrote :

fixed in 1.0-2ubuntu1

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.