/etc/profile.d

[woodsman]

I have spent the past many days learning more about Debian. In the hopes of migrating, I am building a migration check list. I notice Debian does not use an /etc/profile.d directory. What is the usual or accepted Debian way for storing these many application-specific environment variables? So far the only option I notice is to dump everything into /etc/bashrc.

Perhaps I missed some threads that could help. If so just point my nose in that direction.

Thanks much.

[woodsman]

Polite bump.

I have found some old discussions online that imply profile.d is not used and that packages must be built to avoid the need for special environment variables. I suppose the latter means executables must be placed in expected path locations and appropriate sym links must be included in the package. If there is more to this then I would be grateful to learn as I am new to Debian (but not Linux based systems).

Thanks.

[nadir]

never heard about it. searched the web. didn't find an explanation.
i guess you are refering to this:
http://lists.debian.org/debian-devel/19 ... 00561.html

psu25682@odin.cc.pdx.edu (Karl M. Hegbloom):
> What if we had an /etc/profile.d (not invented here) where packages
> (like postgresql) could drop a startup file for /etc/profile to source
> in a for f in /etc/profile.d/* loop?
>
> Pros and cons?

- It's shell specific. Similar stuff would be needed for other shells.

- If the package needs it, it's buggy and should be fixed. (The correct
way in that case is to make it a script wrapper aound the actual
program, not assume things are done in /etc/profile.)

- If the package doesn't need it, it's unnecessary clutter that will
fill up my root partition and slow up my logins needlessly. As sysadmin,
I don't want to have to clean up stuff like that after every upgrade.

- If it is meant just as an example, put it in /usr/doc/*/examples.

In summary, I still (as on some earlier occasions when this has been
suggested) that the idea is not worth it.

what is it supposed to do?
or: what are you trying to do?

I suppose the latter means executables must be placed in expected path locations and appropriate sym links must be included in the package

never had to do something like that.

[woodsman]

what are you trying to do?

Only trying to understand basic design differences between Debian and other systems. The /etc/profile.d directory is common in other systems. The few discussions I have found online such as the one you linked seem to point to an opinion that profile.d is superfluous or poison. I have not found any significant reason why profile.d is not supported. Sure, I can do anything I want with my system and modifying scripts and startup files is nothing new to me, but being new to Debian I would like to read something "official" why Debian does not support profile.d.

[danielibarnes]

I, too, wondered why Debian had no /etc/profile.d. I did some research, and the argument goes back more than ten years. In the meantime, all the other distributions implemented this five-line feature. It's useful, it works, everyone does it, so why not? Section 9.9 of the Debian Policy states:

A program must not depend on environment variables to get reasonable
defaults. (That's because these environment variables would have to
be set in a system-wide configuration file like `/etc/profile', which
is not supported by all shells.)

If a program usually depends on environment variables for its
configuration, the program should be changed to fall back to a
reasonable default configuration if these environment variables are
not present. If this cannot be done easily (e.g., if the source code
of a non-free program is not available), the program must be replaced
by a small "wrapper" shell script which sets the environment variables
if they are not already defined, and calls the original program.

Here is an example of a wrapper script for this purpose:
#!/bin/sh
BAR=${BAR:-/var/lib/fubar}
export BAR
exec /usr/lib/foo/foo "$@"

Furthermore, as `/etc/profile' is a configuration file of the
`base-files' package, other packages must not put any environment
variables or other commands into that file.

No justification is given. It is simply official policy. However, reasons can be distilled from this and other arguments:

1) It is shell-dependent.
There exist solutions which involve creating multiple shell-dependent scripts to address the common shells.

2) It applies to all logins regardless of whether or not they need it.
Most discussions revolve around setting environment variables like JAVA_HOME. Can the cost (in processor time) of setting an environment variable really exceed the value (in convenience) of having it?

3) It is yet one more configuration file to track during installation, upgrade, and removal.
A package can have many configuration files. Does there exist an example of how one more file can be an issue?

4) A package is broken if it depends on an environment variable setting.
How is adding multiple wrapper scripts with the same setting to a package cleaner than adding one file containing the setting? Are the LSB and nearly every other distribution "broken?"

The only way I see this as a practical policy is from a design perspective:
1) It is possible for packages to add script which can break the login process involving rare corner-cases. This could allow for the introduction of a hard-to-find bug.

2) Because the scripts are sourced, it is possible for hidden dependencies to exist between packages.

I don't mind adhering to policy or standards, but we need solid reasons why or the argument will never end. If it can't be defended in simple terms like the two I mentioned above, is it really good policy?

[smallchange]

I like it the way it is, for all the reasons you stated. Good job, Debian.

[nadir]

as this is the beginners section may i ask once again:
what exactly is /etc/profile.d supposed to do?

[danielibarnes]

what exactly is /etc/profile.d supposed to do?

When you login the system will execute certain scripts before presenting you with a prompt. The first is /etc/profile. The second is ~/.profile. This allows for system settings which are executed at every login (like PATH) and per-user settings like the prompt string.

[nadir]

and bash doesnt read /etc/profile and ~/.profile anyway? i have thought so, but did never really care.
anyway, i got a first idea, so thanks for that.

[smallchange]

In systems that use it files in /etc/profile.d are sourced when /etc/profile is read so it is as if those files had been added to /etc/profile without having actually changed /etc/profile.