Re: Another possible slink goal (multipackages users profile)
Calm down, there's a misunderstanding.
Brian Mays wrote:
>
> 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?
But the system administrator has to know how this works for bourne
shells, c shells, z shells, k shells, rc, es etc. I for myself know
bourne shells, well, if I'm reminded also c shells but here it ends.
If I knew, hook it up at /etc/env and call update-env afterwards
and you're done, I would be happy.
> 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.
I believe there's a second but I don't recall it.
> > . 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.
Isn't there a mechanism implemented to user ~/.dircolors?
Even if not, yes *you* would have to call dircolors twice. But that's
only you, all other 230 users on that system would be satisfied by
coloured ls.
If you're the only user on that system you're still able to remove
any colour definition from /etc/env.
> > . 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.
I'm apologize that I haven't pointed this out clear enough. It was meant
as an example. I didn't mean the fortunes package to force every system
to display fortunes. Although I found this on the first unix system I had
to work on and I always found it nice to start work with some lousy idiom.
On on machine that I maintian there's a special fortune call in the profile
and my users like it:
/usr/local/bin/fortune 45% infodrom 45% linux 10% fortunes
As you can guess there are two partially local generated databases
that are used with high preferences.
> > . Maybe: Force the use of proxies
>
> This should be up to the local sysadmin, shouldn't it?
Yes, of course!
But at the moment there is *no* easy mechanism to achieve this.
That's the reason why I prefer a general solution that makes maintenance
of systems easier.
> > . 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
When I say system-wide I mean system-wide. If I would have meant
distribution-wide I would have written that.
It doesn't count a penny what kind of PS1 we ship as default. It
would be nice if there would be a way to keep it consistant through
all shells and to give the local sysadmin the opportunity to use a
different prompt *through all shells* and let the uses define custom
prompts if they like.
Now that I re-think about this, I believe this is not easily achievable
since the shells use different interpretations of contents of PS1.
> 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).
Hey, this doesn't count. We ship a default - we already do - and we
give the sysadmin the opportunity to modify it at _one_ place and to
get the results to all 6 different shells. At the moment he would have
to change it at six places. This is nasty.
> > . 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?
Args. You don't get the point. Yes, the sysadmin can achieve this but
he has to know the mechanism of _every_ shell. Using our new mechanism
he only has to know one mechanism that gets translated to all six shells.
> > . 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
Blah, this was another example for a theoretical system/system administrator.
Give him the opportunity, don't force him to learn programming, syntax
and internal structures of every possible shell.
> /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.
I'm not speaking of package utilities.
> > > 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?"
Whatever the sysadmin decides.
Again: Don't force people to learn and use tons of things, give them
the opportunity to use one mechanism that translates things for them.
This will make administrators happy.
> > 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?
This gets nasty. We're NOT, NOT, NOT, NOT, NOT, NOT, NOT speaking of
the package.
> 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,
or four or five and has to know that much languages and mechanisms.
Yes, right, that's really easier that learning one very easy control
structure that gets translated into all six.
> 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.
Wow! Then I wonder why I had to explain it five times above?
> administrator runs and has complete control over, not something that
> automatically sticks junk in the shell startup sequence.
Mainly speaking yes. Seems you got it, although it doesn't look that
way above.
Regards,
Joey
--
VFS: no free i-nodes, contact Linus -- finlandia, Feb '94
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: