Your message dated Fri, 18 Nov 2016 15:16:35 +0100
with message-id <[email protected]>
and subject line Re: Bug#844725: libproj12 should conflict with libproj9
has caused the Debian Bug report #844725,
regarding libproj12 should conflict with libproj9
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
844725: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844725
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: proj
Version 4.9.3-1
Severity: Serious
Justification: breaks unrelated software when both libraries are installed.
Hi, as said, it took me two days to debug to understand this failure
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/m/mipp/20161118_053933_5e50e@/log.gz
the python binding fails and segfaults when both libproj9 and libproj12 are
installed
(Reading database ... 65663 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [05:39:15]: test python2: [-----------------------
=== python2.7 ===
test_tsx (test_xsar.Test) ... Segmentation fault (core dumped)
autopkgtest [05:39:23]: test python2: -----------------------]
autopkgtest [05:39:23]: test python2: - - - - - - - - - - results - - - - - -
- - - -
python2 FAIL non-zero exit status 139
autopkgtest [05:39:23]: @@@@@@@@@@@@@@@@@@@@ summary
python2 FAIL non-zero exit status 139
a no-change rebuild of mipp with both runtime libraries installed triggers the
failure.
Since you can't force people from autoremoving the old libraries, I think this
is an RC bug, and some sort
of conflict with previous version should be added to prevent such segfaults
from happening.
thanks for understanding,
Gianfranco
--- End Message ---
--- Begin Message ---
On 11/18/2016 02:49 PM, Gianfranco Costamagna wrote:
> can we please keep it open for some days, to discuss it? :)
> I don't feel comfortable in writing to a closed bug ;)
No, I do not intend to keep this issue open. It is not something I
consider to need fixing in Debian, it's an Ubuntu specific issue.
>> Sorry to hear you wasted your time. Thank for caring about packages in
>> universe though, too few people in Ubuntu do.
>
> not a problem, it wasn't wasted, but a good learning opportunity.
>
>> Transitions ensure that all reverse dependencies are updated for the new
>> library thereby making it obsolete and easy to remove with `apt-get
>> autoremove`. By having all rdeps depend on the new library package, the
>> old one should no longer be installed via (build) dependencies.
>
> you can't force people to uninstall a library on their system, I had this
> issue
> with libpng12, that is probably still installed on some Debian chroots
> (according to
> the various binNMU requests in release.d.o, seems that even developers are
> not cleaning
> their systems)
I don't have to force people to uninstall an obsolete library, apt will
recommend their removal when no rdeps depend on it any more.
If people encounter this issue, it should provide ample motivation to
remove the obsolete libraries.
>> The failure in Ubuntu to do a proj transition does not warrant an RC bug
>> in Debian.
>
> this isn't a failure in Ubuntu to transition proj, in fact I did it
> successfully.
Why is the old libproj9 still being pulled in via (build) dependencies
then? That shows that the transition is not completed yet.
>> Conflicts are not appropriate because libproj9 and libproj12
>> do not contain the same files
>
> they are appropriate for my policy parsing:
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
>
> Conflicts should be used
> [...]
> in other cases where one must prevent simultaneous installation of two
> packages for reasons that are ongoing (not fixed in a later version of one of
> the packages) or that must prevent both packages from being unpacked at the
> same time, not just configured.
If you want to prevent both packages from being unpacked at the same
time, please add this as an Ubuntu diff to the package. It will fix your
issue in Ubuntu (which we don't experience in Debian where the
transition was done properly). The Ubuntu diff will have the nice side
effect of blocking automatic syncing of new proj revisions from Debian,
causing the proj package in Ubuntu to become outdated which hopefully
triggers people to start helping maintain the GIS packages in Ubuntu.
>> The fix for this issue is to do a proj transition in Ubuntu as we've
>> done in Debian. If Ubuntu does not have the manpower to do transitions
>> for packages in universe, they should consider removing those packages
>> to acknowledge their lack of maintenance in Ubuntu. Removal of packages
>> Ubuntu users rely on should motivate them to become involved in their
>> maintenance in a similar fashion as removal from testing in Debian.
>
> please don't blame Ubuntu, I'm discussing a totally different issue here.
I do blame Ubuntu, I'm greatly unhappy about my packages not being
maintained in Ubuntu but still being included in their repository.
I appreciate you trying to coordinate this issue with the maintainers in
Debian, this is very uncommon and a source of my displeasure about Ubuntu.
> Since you can't force people from not having two different incompatible
> libraries, at least
> you should enforce python-pyproj in using the correct one, because as you can
> say there,
> apt is not preventing usage of libproj9 together with python-pyproj and the
> wrong gdal binding.
python-pyproj (in Debian) has a dependency on libproj12 which is
correct, there are other packages in Ubuntu which are still pulling in
the old library because the transition has not been completed yet.
The old gdal packages are likely still pulling in the old libproj,
because the gdal transition is still ongoing and so only the gdal in
proposed depends on libproj12.
When the proj transition is done properly in Ubuntu, none of its rdeps
will pull in libproj9 and resolve your issue.
> this is the issue, the dependencies should have the correct relationships, to
> avoid such issues,
> during upgrades or when people selectively picks what to keep and what to
> upgrade.
The packages do have the correct relationships. Ubuntu seems to just
suffer from entangled transitions which were properly separated in
Debian. That's not something to fix in Debian.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
--- End Message ---
_______________________________________________
Pkg-grass-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
