Bug#844725: libproj12 should conflict with libproj9
Hi, >You have not explained why the old libproj9 is still being pulled in via >the build dependencies on Ubuntu. because the testsuite is not ran by default against every "proposed" package, but against release pocket (you can call them testing and unstable if you like) This is done because we want to test the single change, not against something huge that might have a lot of regressions or ongoing transitions. >How are autopkgtests causing the old packages to be pulled in when the >transition has been completed in Ubuntu? same as above, to see regressions usually the best way is to restrict changes to the bare minimum >You are contradicting yourself. First you claimed that the transition >was completed, now you're implying that it's still ongoing. rebuilds are complete, to migrate it still needs some other transitions to finish. -release is ok with the old library -proposed is ok with the new library. So, the transition is finished, but needs migration because of something else. >My point is that Ubuntu includes all packages from Debian, and most of >them in universe because it cannot support them all. Because there are >no people actively maintaining those package, like coordinating >transitions and handling bugs, the packages are prone to cause issues. >MOTU tries to deal with the many packages in universe, but is unable to >cope with them all. they can cope with this one. >Yes, the openssl situation in unstable is good example of fallout caused >by a badly thought out transition. openssl 1.1.0 shouldn't have been >made the default because it was known many packages did not support it yet. this is true, I hope I don't get autoremovals because of this, even if release acked special unblocks for them :) (it would have been unfair otherwise) >Why is libproj9 still being pulled in via the dependencies? because of testsuite confined to -release >The transition tracker disagrees, mysql-workbench is still marked as bad. http://people.canonical.com/~ubuntu-archive/transitions/html/html/libproj.html I don't see any mysql-workbench here, anyhow, the reason for it not migrating is: some rebuilds are still ongoing (for other entangled transitions), some architectures needs fix/removals/decruft for other stuff G.
Bug#844725: libproj12 should conflict with libproj9
On 11/18/2016 06:02 PM, Gianfranco Costamagna wrote: >> Why is the old libproj9 still being pulled in via (build) dependencies >> then? That shows that the transition is not completed yet. > > ok You have not explained why the old libproj9 is still being pulled in via the build dependencies on Ubuntu. >> 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. > > I know how Ubuntu works, the only reason for you not experiencing this issue > is that autopkgtestsuite isn't run or at least is not a blocker for a testing > migration. > I know the situation auto-heals by itself at the end (like it did already), > but this will become a blocker one day if Debian starts doing autopkgtests. How are autopkgtests causing the old packages to be pulled in when the transition has been completed in Ubuntu? >> I do blame Ubuntu, I'm greatly unhappy about my packages not being >> maintained in Ubuntu but still being included in their repository. > > they are maintained and they still work completely, I don't understand your > point > and I find it completely invalid, because also debian sid is broken in the > middle > of a transition, I don't really get the point. You are contradicting yourself. First you claimed that the transition was completed, now you're implying that it's still ongoing. My point is that Ubuntu includes all packages from Debian, and most of them in universe because it cannot support them all. Because there are no people actively maintaining those package, like coordinating transitions and handling bugs, the packages are prone to cause issues. MOTU tries to deal with the many packages in universe, but is unable to cope with them all. > Openssl is broken since almost one month, should I say the same about Debian? Yes, the openssl situation in unstable is good example of fallout caused by a badly thought out transition. openssl 1.1.0 shouldn't have been made the default because it was known many packages did not support it yet. >> 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. > > it is completely common to transition packages, and to coordinate them > in the same way Debian does, and since there is no "testing" or "sid", > it is not so important if a transition takes some days more to finish, > specially > when full autopkgtests needs to run to make it migrate, and it works better > than Debian, since we can spot build or test failures even with a > non-completely > migrated combination of packages (specially when many transitions are > entangled, > the testsuite needs to run against -proposed packages to pick also the > ongoing work) > >> 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. > > there are none. Why is libproj9 still being pulled in via the dependencies? >> 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. > > gdal is finished, will migrate when other transitions ends The transition tracker disagrees, mysql-workbench is still marked as bad. >> When the proj transition is done properly in Ubuntu, none of its rdeps >> will pull in libproj9 and resolve your issue. > > it is properly done, and ended already, waiting for other transitions to end Why is libproj9 still being pulled in via the dependencies? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#844725: libproj12 should conflict with libproj9
control: reopen -1 Hi Sebastiaan, can we please keep it open for some days, to discuss it? :) I don't feel confortable in writing to a closed bug ;) >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) >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. >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. >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. 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. 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. I hope it is clear now. G.
Bug#844725: libproj12 should conflict with libproj9
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
