[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Tips for debugging/testing debian/control Depends/Breaks etc changes?

On Wed, Mar 24, 2021 at 12:37:46PM -0400, Otto Kekäläinen wrote:
> I've noticed I've spent quite a lot of time debugging various
> situations where the debian/control definitions for
> depends/breaks/replaces/conflicts/provides are not optimal.

Thanks for asking about this, I could also use some tips!  I have some
ideas that aren't great.  Hopefully somebody has better ones.

> The waste of time is two-fold:
> 1) apt is not verbose enough
> 2) the cycle to rebuild/tests is too slow
> As an example of 1, sometimes I see this:
> apt install mariadb-client
>  The following packages have unmet dependencies:
>  mariadb-client : Depends: mariadb-client-10.5 (>= 1:10.5.10) but it
> is not going to be installed
> apt install mariadb-client-10.5
>  Installing.. Done!
> When this happens I have no idea why apt did not resolve the
> dependency by itself automatically, as there was no real conflict in
> installing it.
> Do you have tips on how to debug the root cause of situations like these?

Sometimes I try aptitude's interactive solver - I keep saying 'n' to the
alternatives and try to spot a pattern.  It's not a great technique, I
don't know if it could help with your case above - I'm usually looking
at upgrades of numerous packages at once.

I'd like to be able to automate testing relationships: provide some
constraints that I know should be satisfied, and have a tool
automatically check them based on the source and built packages.  I
wonder if there's any prior art?

> For the problem 2, I hate to rebuild all of the packages (and
> binaries) just because there was a change in debian/control and go
> through the hassle of updating a test repo etc.
> I wonder if there is some other "lighter" way to just edit the
> debian/control and produce new binary packages with them updated
> without having to actually build new binary packages (and no, editing
> the .deb files manually and repackaging them with 'ar' is not an
> option that would make life easier).

`dpkg-buildpackage -nc` skips the clean - this can at least avoid the
recompile.  I don't know how to do this in a chroot though, so I have to
flip out of sbuild.


Reply to: