Package conflicts trying to install jpegdupes package

Chris Angelico rosuav at gmail.com
Mon Sep 27 14:16:58 EDT 2021


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.

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

ChrisA


More information about the Python-list mailing list