Hi,

I was trying to fix "enigmail" FTBFS, and discovered that it was
simply missing all the packages that "eslint" recommends.

enigmail
Build-Depends:
 eslint <!nocheck>,
 node-chalk <!nocheck>,
 node-strip-ansi <!nocheck>,
 node-text-table <!nocheck>

Those three packages are not explicitely called by enigmail's eslintrc config:
they should just be in eslint Depends, because they are required to make eslint work.

Jérémy

tags -1 wontfix

Quoting Jérémy Lal (2022-05-02 09:50:54)

Those are not _always_ needed for eslint, only _often_ which is the
exact purpose of "Recommends.

Please include those recommended packages as build-dependencies, or
patch/override configuration to not use them: They are related to how
eslint outputs information, and since ideally packaging should be
verbose/terse depending on build flags you would want to manage such
configuration anyway.

I commonly add something like this near the top of the rules file:

ESLINT = NO_COLOR=1 eslint
JEST = jest --color=false
MOCHA = NO_COLOR=1 mocha --no-timeout --no-color
# normalize output with TAP where possible unless terse requested
ifeq (,$(filter terse,$(DEB_BUILD_OPTIONS)))
ESLINT += --format tap
MOCHA += --reporter tap
else
ESLINT += --format unix
MOCHA += --reporter dot
endif


...and then call $(ESLINT)/$(JEST)/$(MOCHA) in target rules.


Hope that helps,

 - Jonas

Le lun. 2 mai 2022 à 11:24, Jonas Smedegaard <jonas@jones.dk> a écrit :


It also breaks separation of concerns and will lead to an unmaintainable
mess,
if applied globally.

Please include those recommended packages as build-dependencies, or

Instead of making other packages know about eslint internals,
wouldn't it be simpler to make eslint default to a reporter that "just
works" ?

Currently enigmail just naively calls "eslint --quiet", and its .eslintrc
are innocent,
they don't select a particular output.

I stand by saying as it is, putting those packages:
node-chalk
node-strip-ansi
node-text-table
in Recommends just breaks the default functionality of eslint.

Jérémy

Quoting Jérémy Lal (2022-05-02 11:45:36)

Ignoring recommends breaks systems.

 - Jonas

Le lun. 2 mai 2022 à 11:54, Jonas Smedegaard <jonas@jones.dk> a écrit :

eslint is a build-dependency of enigmail (nothing odd about that).
When sbuild builds a package, it doesn't install recommended packages of
build-dependencies ?

Quoting Jérémy Lal (2022-05-02 11:59:15)
build-dependencies, when needed.

That does not mean that the package is broken (as you wrote).


 - Jonas

Le lun. 2 mai 2022 à 12:24, Jonas Smedegaard <jonas@jones.dk> a écrit :

I don't discuss the usefulness of Recommends.

I'm trying to argue why in the particular case of eslint and of those three
packages
(mentioned above) you put in Recommends, it breaks eslint for other packages
Build-Depending on eslint.

Adding those Recommends in Build-Depends is not a good practice, IMO,
for this reasons:
- separation of concerns
- Build-Depends eslint does not install Recommends resulting in a broken
eslint
- when some eslint recommends change, build-dependent packages will just
break again !
- worse (because undetectable) build-dependent packages will uselessly
build-depend on
no longer required packages.

Is there a strong reason to put those three packages in Recommends ?
The economy of installing three additional small packages is outweighed by
the
over-engineering needed to cope with it.

Jérémy

Le lun. 2 mai 2022 à 12:48, Jérémy Lal <kapouer@melix.org> a écrit :

Because of that, I think it's desirable to ask for eslint maintainer (Jonas)
to also maintain packages Build-Depending on eslint... or at least, maintain
these packages's Build-Dependencies, because only the eslint maintainer
knows
what he meant to go in there, for eslint to work.

Jérémy