Comment 1 for bug 18808

This does get asked quite a lot, and there is an answer for why it hasn't been
added in /usr/share/doc/base-files/FAQ:

  * Questions about "profile.d":

  Q. Why does Debian not have a "profile.d" directory, like other distributions?

  A. Because no Debian package needs it. Debian policy says: "A program
  must not depend on environment variables to get reasonable defaults".
  This policy has been very successful so far. If the default install
  had a profile.d, people might think it's ok to use it for a Debian
  package, when in fact policy does not support such thing.

  Q. Ok, but I still think it would still be a nice thing to have, would
  not make sense to have a profile.d by default, even if no Debian
  package uses it?

  A. No. As explained before, there is the risk of assuming that it's
  "officially supported". If you need a profile.d directory, you may
  still create one in your machine and modify your /etc/profile
  accordingly to enable it. Since this is a configuration file,
  its contents will be preserved in upgrades.

I do agree that the "packages must not rely on environment variables" policy
makes sense; things like bash_completion are integrated into the bash package,
which supplies its own skeleton startup scripts, and other "add-on" features are
often best handled by shipping example files that users can source if they want
those features (I'm comparing this with things like SuSE's default vim
configuration which enables features that are difficult for users to switch off
once they've been globally enabled).

However, are there particular examples among your local packages that are giving
you trouble here?