[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#934948: Unnecessary dependencies vs multiple binary packages



On Wed, 21 Aug 2019 at 22:59:50 +0530, Pirate Praveen wrote:
> On 2019, ഓഗസ്റ്റ് 21 7:06:34 PM IST, Simon McVittie <smcv@debian.org> wrote:
> >* As far as I can tell, the command-line executable
> >`.../bin/autoprefixer`
> >  is not in the PATH. I don't know whether it is run automatically in
> >  some other way, analogous to a program in /usr/libexec.
> >  - Please fact-check: is it in the PATH? Is it run as an executable
> >    in some other way?
> 
> I was not using this command personally so I was OK to remove nodejs
> dependency if it was rejected.

That doesn't answer my question.

I looked at this executable again and it seems as though its purpose is
to query metadata about the autoprefixer nodejs library, analogous to
the -config programs sometimes found in -dev packages (sdl2-config and
so on). Is that correct?

Is it run automatically by some piece of Node infrastructure (like the
way the build systems of some SDL games automatically run sdl2-config
to learn which compiler and linker options they should use for SDL),
or is it intended to be run manually by a developer, or what?

Is there any situation in which it would be run by a developer who does
not already know that they have nodejs installed?

> So in general there is two cases I want to be able to create multiple binaries.
> 
> 1. Cases like node-autoprefixer if the executable is useful (in specific case of node-autoprefixer , I can live without the executable for now).
> 2. Cases like ruby-task-list where there is more dependencies than the interpreter.

I think these are different, and each should be considered on its own
merits, so this bug might make more sense if it is cloned (split) to offer
advice on the two different situations.

For the node-autoprefixer case, if we decide that the executable is not
sufficiently important to the overall function of the package to merit a
dependency, it's probably useful to compare and contrast with cleancss.deb
from the node-clean-css source package (which *is* a separate binary
package, and it looks to me as though that was the correct decision).

    smcv


Reply to: