Adding to what @gcusello and @richgalloway already said, if it's a standard Splunk-supported app (I suppose by TA_Linux you mean the TA_nix but I can't be 100% sure), it will have its own docs page saying on which components it should/can be installed.
If it's a third-party supplied independently written app it might have such doc page as well.
Generally speaking, Splunk apps contain settings which can be active on various components (either in search-time or in index-time) but if an app is properly written (and as far as I remember, there are checks which make sure that you can upload to Splunkbase a badly written app; at least badly written in this context), you can typically deploy your app on all tiers and each tier will only "use" the part of the app which applies to said tier.
So your app may contain:
1) Input/output definitions - in an Splunkbase-supplied app they will be set as disabled by default; you have to explicitly enable them so if you just deploy an app with disabled inputs, they won't do anything anywhere. Of course if you're deploying your own custom app with enabled inputs or ouptuts they will try to do their job whenever they are deployed
2) Index-time props/transforms settings - they will be active either on the initial forwarder (if applicable - like EVENT_BREAKER settings) or on the first "heavy" (based on full Splunk Enterprise installation) component in event's path (except ingest-actions; they will be performed after the initial parsing as well but that's a story for another day ;-)). Splunk will happily ignore them in search-time
3) search-time props/transforms settings - they will be active only on search-heads. You can safely deploy them to components active during ingestion phase (HFs and indexers) and they will simply be ignored in ingestion pipeline
