apt-get --purge -yf build-dep hello, fails with E: Command line option ‘f’ [from -yf] is not known.

[Dimitri John Ledkov]

apt-get --purge -yf build-dep hello, fails with E: Command line option ‘f’ [from -yf] is not known.

this thus breaks sbuild cross-builds. another regression ?

[Michael Vogt (mvo)]

Hey Dmitrijs,

thanks for your bugreport. The "-f" flag means "--fix-broken" and is not used by apt the context of build-dep. This is why its complaining. If it breaks sbuild we can add it back, but note that it does not have any effect AFAICT (looking at the apt source).

[Dimitri John Ledkov (xnox)]

On 28 November 2013 16:29, Michael Vogt <email address hidden> wrote:
> Hey Dmitrijs,
>
> thanks for your bugreport. The "-f" flag means "--fix-broken" and is not
> used by apt the context of build-dep. This is why its complaining. If it
> breaks sbuild we can add it back, but note that it does not have any
> effect AFAICT (looking at the apt source).
>

Above is actually a regression, which causes sbuild to fail when using
AptResolver when cross-compiling. I don't know if "-f" actually does
anything when above command is invoked.

As per manpage all options apply to all sub-commands, and there are no
per sub-command options/restrictions. ( [-asqdyfmubV] )

specifically, why is "-f" rejected yet at the same time:
    apt-get -oAPT::Get::Fix-Broken=true --purge -y build-dep hello
is accepted?

Similarly "--purge" had to be unbroken, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720597

Removing options, breaks compatibility, thus shouldn't be done in a
point release of such a core utility which is used in scripts.

Regards,

Dmitrijs.

[Michael Vogt (mvo)]

Right, I'm sorry for the trouble and I agree that it would have been better to put the erroring into 0.10.0 instead of 0.9.13.

I will add "-f" back so that sbuild is unbroken. Note that it has no effect on "buil-dep" (it does on "source").

Cheers,
 Michael

[Dimitri John Ledkov (xnox)]

On 28 November 2013 18:43, Michael Vogt <email address hidden> wrote:
> Right, I'm sorry for the trouble and I agree that it would have been
> better to put the erroring into 0.10.0 instead of 0.9.13.
>
> I will add "-f" back so that sbuild is unbroken. Note that it has no
> effect on "buil-dep" (it does on "source").

Thanks a lot!

Regards,

Dmitrijs.

[Launchpad Janitor (janitor)]

This bug was fixed in the package apt - 0.9.13.1~ubuntu1

---------------
apt (0.9.13.1~ubuntu1) trusty; urgency=low

  [ Colin Watson ]
  * fix "apt-get --purge build-dep" (closes: #720597)
  * fix regression that APT::Keep-Fds is not honored (closes: #730490)

  [ Michael Vogt ]
  * add "-f" option to "build-dep" as sbuild is using it to fix
    regression with cross-building (LP: #1255806)
  * merge mvo/feature/short-list

apt (0.9.13) unstable; urgency=low

  [ TJ Guthrie ]
  * Changed MinAgeSec to MinAge in /etc/cron.daily/apt:200,204
    LP: #1206047
 -- Michael Vogt <email address hidden> Thu, 28 Nov 2013 21:17:43 +0100

[David Kalnischkies (donkult)]

Still, could you please fix sbuild to not use options which do nothing Dmitrijs?

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 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 ;) ]

[Dimitri John Ledkov (xnox)]

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 man...