Comment 7 for bug 1255806

On 28 November 2013 23:02, David Kalnischkies
<email address hidden> wrote:
> Still, could you please fix sbuild to not use options which do nothing
> Dmitrijs?
>

Please file a bug against sbuild package. I'm just the messenger.
apt-get, sbuild and cross-builds are critical pieces of software for
ubuntu development. Therefore such changes should be done with minimal
amount of breakage.

> As Michael said, --fix-broken did, does and will not do anything for build-dep, so calling apt with it is just wrong, even if it was accepted in the past. The parsing of the commandline became stricter now as we get frequent reports from people who use this or that flag and assume that it has some effect because the apt-tools accepted them even if they are ignored.
> I could nearly bet that the -f in sbuild is there because someone thought it would stand for --force and so helps in spreading the legend that -f would trigger some more reckless behavior, but it will not…
>
> -o flags are btw always accepted. Regardless if the option in question
> even exists or is used. Were are wishes to change this as well (cupt
> e.g. does), but I think the -o flag should remain mostly unchecked to
> help with backward compatibility.
>
>
> I btw don't agree with waiting for this to be done in a major release. There isn't any transition required. Either the failing scripts fails because they used apt wrongly, so breaking them now is good rather than breaking them at a

There is transition required, sure it's not an "library soname bump",
but it is a change in the CLI API, which is automated. And there are
no ways around it, one cannot keep apt-get blocked in debian/unstable
nor ubuntu/devel-proposed, since newest apt is always used by buildds.
Not breaking buildd / sbuild is a must.

Typically warnings should be emitted for things that will become
fatal. Rebuilds and tests should be done, e.g. codesearch.debian.net
can help to find some of the args that are passed to apt-get.

Uncordinated uploads, of changes that have a high risk of breaking
things is not good. And if apt-get is borked, it's kind of hard to
test it using usual ways (e.g. autopackage tests, reverse dependencies
tests etc.). So simple things like pbuilder / sbuild / other well
known users of apt-get CLI should be checked to "not explode".

>point at which something really changes (like -f gets some sort of meaning for build-dep) or it breaks because it uses an option we forgot about. The later is a bug in APT we can fix easily and nothing special per se. Every change can include bugs after all. And as a by-product we get to know what users assume to be in working condition which we never thought about. If we never thought about it, we might break it in the future with real changes, so writing a testcase for it now might as well protect you from real fallout in the future (again).
> [I e.g. would have never thought to --purge on build-dep. It might make sense for sbuild, but not for myself so I can perfectly imagine breaking it in some silly way – okay, I can't imagine how at the moment, but if its me creating bugs, everything is possible ;) ]
>

To be honest, I don't know C++, so all I read is the manpage:

apt-get [-asqdyfmubV] {update | ... | build-dep pkg ...}

-f, --fix-broken
"Fix; attempt to correct a system with broken dependencies in place.
THis option, when used with install/remove, can.....*"

Well "install/remove" is not formatted as command line option. And
{upgrade|dist-upgrade|dselect-upgrade|install|remove|purge|build-dep|autoremove}
all may install/remove packages. So I naively can honestly say, sbuild
uses flags as documented by apt-get.

Note that *I* didn't use that option, sbuild uses it, and as far as I
know sbuild is the way to clean build/cross-build any debian package.
As a packager, I expect sbuild and apt to never break each other =)

Thanks for the quick fix of this bug.

Regards,

Dmitrijs.