[Pkg-openssl-devel] Bug#863367: libecryptfs-dev: unable to install because of unmet dependency

[David Kalnischkies]

Control: reassign -1 libssl-dev 1.1.0e-2
Control: retitle -1 libssl-dev: declare conflict with libssl1.0-dev to help apt find solutions

On Sat, May 27, 2017 at 09:32:34AM +0300, Adrian Bunk wrote:
> Control: reassign -1 apt
> Control: retitle -1 apt does not find solutions that involve libssl1.0-dev -> libssl-dev
> 
> On Thu, May 25, 2017 at 09:16:30PM +0200, s3v wrote:
> > Package: libecryptfs-dev
> > Severity: grave
> > Justification: renders package unusable

(technically wishlist, but people might disagree in practice, so I will
leave severity decisions at this stage to maintainers/release team –
please realize that this means this bug is RELEASE CRITICAL atm)

General advice:
Don't (re)assign package uninstallabilites to apt. The team has neither
the knowledge nor the manpower to deal with the installation problems of
more than 50000 packages in existance. All it does achieve is that it
will get downgraded on the spot to normal or lower and left to die^Wbe
closed in a couple years in the already existing bugpile; in short:

Not being installable is the problem of the package which isn't
installable – even if that is due to bugs in a package manager!


> libecryptfs-dev Is not actually uninstallable, the core problem is that 
> you have libssl1.0-dev installed and apt fails to find the solution to
> solve the dependencies:
> 
> # apt-get install libtspi-dev
[…]
> root at localhost:/# apt-get install libtspi-dev libssl-dev
[…]
> The other direction works:
> 
> # apt-get install libh323plus-dev

The defining difference between the two is that libssl1.0-dev conflicts
with libssl-dev while the later doesn't with the first.

As you are trying to express a mutially exclusive relationship between
two packages which should both be shipped in the release it would be
a good idea to declare this exclusiveness on both sides and indeed in
a quick test that is already enough to give apt the hint it needs as
this changes the scoring for the little 1on1 cagefights happening behind
the scenes.

Have a look at them with -o Debug::pkgProblemResolver=1
(kids-friendly as no violence is depicted)


That wasn't all to hard to figure out and I am pretty sure that would
have happened just as fast/good if assigned to one of the involved
packages rather than to apt, which always carries the risk of getting
ignored instead… I was actually 2 seconds away from tagging it
'wishlist'¹ for apt and get on with never looking at it again in my
lifetime.

Note that this solution might not be a good one, but that requires
knowledge about the packages involved which I just don't have as hinted
above. Please CC deity at lists.debian.org if there are any questions you
think we could answer.


Best regards

David Kalnischkies

¹ The cagefights are a design decision in the current default resolver,
which is impossible^Whard to change and absolutely not going to happen
any time soon yet alone days before release. As such it would qualify
for 'wishlist'.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-openssl-devel/attachments/20170527/367f77c2/attachment.sig>