Re: Another possible slink goal (multipackages users profile)
I'm not quite sure I understand the purpose here. Any system
administrator can already do these things (with Bourne and C shell
variants, at least) for his system. Are you really sure you want package
maintainers making these decisions?
As for the examples cited, I have some questions.
joey@kuolema.Infodrom.North.DE (Martin Schulze) writes:
> . Call check-sendfile to check the SAFT queue
This is the only example that I think might be useful for a package
to provide.
> . Call dircolors in order to give coloured ls
What if I don't like the default colors? I'll have to run dircolors
twice: once to generate an LS_COLORS environment variable that the
fileutils maintainer likes, and again (in ~/.bash_profile) to regenerate
LS_COLORS for my preferred color scheme. Furthermore, you will also
need to provide a function or alias for ls or the LS_COLORS environment
variable is meaningless.
> . Call fortune so users can smile when they start working
So that if I install the fortune-mod package, I'm automatically annoyed
by stupid messages when I log in? No thanks! This is NOT what I want.
If the administrator of a system on which I had an account put this in
/etc/profile, I'd punch him in the mouth.
Indeed, this kind of thing is exactly why I don't favor this proposal.
> . Maybe: Force the use of proxies
This should be up to the local sysadmin, shouldn't it?
> . Set system-wide consistent shell prompt (I guess PS1 from
> /etc/profile only works for bourne shells?)
Don't you mean a distribution-wide consistent shell prompt, if the Debian
developer is supplying the PS1 variable? Haven't we had this discussion
before? I don't think that we could arrive at a consensus of what the
"better" shell prompt should be. Everyone likes something different;
I happen to like '$ ' (with bash, but that's just me).
Will all shells have the same prompt? Currently, bash prompts typically
end with '$', csh prompts typically end with '%', and tcsh prompts
typically end with '>' or perhaps '%'.
> . Make it possible for the local sysadmin to add local environment
> variables, aliases, functions etc. [where this is possible]
I think that the local sysadmin can do this already, can't he? And what
does this have to do with *packages* being able to supply default values
for environment variables?
> . Add more components to the PATH such as ~/bin if it exits,
> /usr/local/<package>/bin, /opt/<package>/bin etc.
But official Debian packages will not use /usr/local/???/bin or
/opt/???/bin, will they? Therefore, if these directories need to be
added to the PATH, the will need to be added by the sysadmin or the user
and not the package utility.
> > Previously Martin Schulze wrote:
> > > This is a different story. Programs still have to run without that
> > > environment but they may run better with a modified environment.
But what is "better?" Is it your definition or my definition of "better?"
> Wichert Akkerman wrote:
> > Some things can only be configured by environment variables, which
> > really bothers my. Currently I have to set things like http_proxy,
> > MINICOM, MANOPT in all shell-configs. That's annoying.
> Exactly. This is why it would be nice if we could invent such a beas
> as described above.
But minicom and man work perfectly well without the MINICOM or MANOPT
environment variables set. Therefore, does the package maintainer really
need to set these variables?
It is my opinion that a profile.d scheme makes the system harder to
administer. Whereas before I had to worry about one, two, or three files,
now I must worry about a whole directory of little files, which I shall
need to scan every time that I upgrade my system to deactivate something
that a flighty developer happened to put in my login sequence because
he thought it was "useful." As for environment variables and aliases,
I believe that if a program's feature requires an environment variable
to activate it, then it should be off by default, and in the past,
Debian policy has agreed with me.
schizo@debian.org (Clint Adams) writes:
> Even if it is felt that having packages installing such things by
> default (like /etc/ppp/ip-up.d/) is evil, it would still be a handy
> tool for the system administrator to be able to modify shell startup
> behavior in one place one time and have each shell mechanism interpret
> it properly, rather than having to modify the startup scripts for each
> and every shell used on the system.
I agree somewhat with this. But let's keep it a tool, which the system
administrator runs and has complete control over, not something that
automatically sticks junk in the shell startup sequence.
Brian
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: