Bug#810990: libxmlrpcpp-dev: /usr/include/base64.h already shipped by heimdal-dev

[Jochen Sprickerhof]

Hi,

I've pushed changes to libxmlrpcpp-dev to move the base64.h to
/usr/include/xmlrpcpp [1]. Would it be ok if I reassign this to
libxmlrpcpp-dev and close it, or should we split it, to leave one open
for heimdal-dev?

* Wookey  [2016-01-16 03:26]:
> Debian now has this xmplrpc c++ implementation: 
> https://tracker.debian.org/pkg/xmlrpc-c
> maybe ros-ros-comm could just use that? I've not looked to see how well the 
> APIs match up. 

ROS upstream is currently working on ROS2, replacing most of the core
system, so I hope this gets resolved with that.

Cheers Jochen

[1] 
http://anonscm.debian.org/cgit/debian-science/packages/ros/ros-ros-comm.git/commit/?id=d363634441477378be652ef328c12cf7bb3c6995


signature.asc
Description: PGP signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#810990: libxmlrpcpp-dev: /usr/include/base64.h already shipped by heimdal-dev

[Jelmer Vernooij]

On Tue, Jan 19, 2016 at 09:38:35AM +0100, Jochen Sprickerhof wrote:
> Hi,
> 
> I've pushed changes to libxmlrpcpp-dev to move the base64.h to
> /usr/include/xmlrpcpp [1]. Would it be ok if I reassign this to
> libxmlrpcpp-dev and close it, or should we split it, to leave one open
> for heimdal-dev?
> 
> * Wookey  [2016-01-16 03:26]:
> > Debian now has this xmplrpc c++ implementation: 
> > https://tracker.debian.org/pkg/xmlrpc-c
> > maybe ros-ros-comm could just use that? I've not looked to see how well the 
> > APIs match up. 
> 
> ROS upstream is currently working on ROS2, replacing most of the core
> system, so I hope this gets resolved with that.

Heimdal already ships a package (heimdal-multidev) that moves these files into
/usr/include/heimdal. 

heimdal-dev currently merely ships symlinks to these files in /usr/include
for backwards compatibility reasons. I'll see if we can remove the backwards
compatibility symlinks.

Cheers,

Jelmer

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#810990: libxmlrpcpp-dev: /usr/include/base64.h already shipped by heimdal-dev

[Wookey]

The two base64.h files are not at all similar, so just referring to the other 
one does not help.
heimdal's just provides two function headers (in a win32-compatible way):
ROKEN_LIB_FUNCTION int base64_encode(const void *, int, char **);
ROKEN_LIB_FUNCTION int base64_decode(const char *, void *);

The ros-ros-comm one provides a whole base64-encode/decode C++ implementation.

I've not looked to see how much commonality there is in the other 101
'base64.h' include files in all the other packages. I do wonder if a
libbase64-dev is what's really needed here.  The file comes from an
embedded xmlrpcpp implementation from Chris Morley which should
probably be packaged separately anyway.
http://sourceforge.net/projects/xmlrpcpp/
Which is seems used to be in debian but was removed in 2008: 
https://tracker.debian.org/pkg/xmlrpc++
That is the same version. Available here: 
http://snapshot.debian.org/package/xmlrpc%2B%2B/0.7%2Bcvs20040713-2.1/
This could be resurrected. I think it has the same base64.h file clash though.

Debian now has this xmplrpc c++ implementation: 
https://tracker.debian.org/pkg/xmlrpc-c
maybe ros-ros-comm could just use that? I've not looked to see how well the 
APIs match up. 

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#810990: libxmlrpcpp-dev: /usr/include/base64.h already shipped by heimdal-dev

[Andreas Beckmann]

Package: libxmlrpcpp-dev,heimdal-dev
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite
Control: found -1 1.11.16-2
Control: found -1 1.6~rc2+dfsg-10

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:

  Selecting previously unselected package libxmlrpcpp-dev.
  Preparing to unpack .../libxmlrpcpp-dev_1.11.16-2_amd64.deb ...
  Unpacking libxmlrpcpp-dev (1.11.16-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libxmlrpcpp-dev_1.11.16-2_amd64.deb (--unpack):
   trying to overwrite '/usr/include/base64.h', which is also in package 
heimdal-dev 1.6~rc2+dfsg-10
  Processing triggers for libc-bin (2.21-6) ...
  Errors were encountered while processing:
   /var/cache/apt/archives/libxmlrpcpp-dev_1.11.16-2_amd64.deb


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  usr/include/base64.h

This bug is assigned to both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may
also register in the BTS that the other package is affected by the bug.

/usr/include/base64.h sounds like a very generic name and I wouldn't
expect to find such a file in either of these two packages.
There are a lot of packages shipping base64.h in their specific include
directories:
https://packages.debian.org/search?searchon=contents=base64.h=path=unstable=any

Cheers,

Andreas

PS: for more information about the detection of file overwrite errors
of this kind see https://qa.debian.org/dose/file-overwrites.html

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers