Package conflicts trying to install jpegdupes package

[2QdxY4RzWzUUiLuE at potatochowder.com]

On 2021-09-28 at 04:16:58 +1000,
Chris Angelico <rosuav at gmail.com> wrote:

> On Tue, Sep 28, 2021 at 4:04 AM <2QdxY4RzWzUUiLuE at potatochowder.com> wrote:
> >
> > On 2021-09-28 at 03:23:53 +1000,
> > Chris Angelico <rosuav at gmail.com> wrote:
> >
> > > On Tue, Sep 28, 2021 at 3:11 AM Skip Montanaro <skip.montanaro at gmail.com> wrote:
> > > >>
> > > >> Those are all warnings. Are there any errors that follow them?
> > > >
> > > >
> > > > Maybe I just missed the actual errors, but the compiler exit status was 1, so there must have been. I'll give it another try.
> > >
> > > Yeah, one of the annoying things of building large C packages is when
> > > the maintainers don't care about warnings, and then legit errors get
> > > lost in the spam.
> >
> > It's also possible that the compiler is running in a "warnings are
> > errors" mode.  Hack the Makefile (or equivalent) at your own peril.
> >
> > One of the annoying things about warnings is that they're not standard,
> > so squelching them under one compiler makes another compiler (or a
> > different version of the same compiler) whine.  IIRC, a compliant C
> > compiler can issue a warning for anything it wants, including "this
> > variable name contains too many vowels" or "this is a computer, and
> > today may be Tuesday."
> >
> > In many ways, the engineering pieces of software engineering remain in
> > their infancy.  *sigh*
> 
> But that's kinda the point of having different compilers. Warnings
> that we consider fairly standard today didn't exist in the past, and
> someone had to be the first to add them. If the C language had to
> mandate every warning, it'd take forever to make changes.

That is indeed one benefit of having different compilers and compilers
that improve over time.  It's also a nuisance when the compiler in your
development/unit test environment produces different warnings than
either cross compiler for your target environments (plural).

In Python, it's more likely that MSVC, MinGW, LLVM, and gcc choose
different warnings, and that no collection of settings supresses them
all.  Present C projects contain oodles of conditional compilation,
often controlled by the preprocessor; achieving ideal results can be,
well, "tricky."  It's not a matter of not caring.

At some point, it comes down to a question of ignoring a warning vs.
cluttering up your code (preprocessor or otherwise) with extra
conditionals.  Or being stuck with a warning about unneeded defensive
programming vs. being stuck with a warning about possible arithmetic
overflow on your 32-bit target.

I agree that the standard shouldn't regulate warnings.  I'm also saying
that sometimes, it's a pain that it doesn't, and that not every warning
is the package maintainer's fault.  :-)

> I don't think that warnings-are-errors mode is a good thing though.
> They should remain just as warnings. (And with the most popular
> compilers, using the compilation options as specified in their own
> makefile, maintainers should ideally try to ensure that there are as
> few warnings as possible.)

Ideally, yes.