Re: Another possible slink goal (multipackages users profile)
I think you're on the right track here.
Martin Schulze wrote:
> . /etc/env contains information about variables, aliases and
> programs that have to be called when a user logs in
>
> . A general package knows about the syntax of various shells and
> how they issue a global profile.
>
> . A program update-env is invented that uses the information from
> above and creates appropriate profiles
>
> . env-add and env-remove are invented to serve /etc/env in order to
> give packages the possibility to install/remove entries from it.
>
> . All programs that use env-add / env-remove have to call update-env
> (maybe it should consitantly be called env-update) in their postinst
> and it uses the same mechanism like update-menus in order to not
> run in 10 instances.
I disagree with this. The real reason update-menus backgrounds itself and
runs after dpkg is that it needs to be able to see what the dpkg status file
looks like after dpkg is done installing packages. Update-env doesn't need
this, so it shouldn't use this complicated and error-prone mechanism.
> . All shells must know a mechanism to read and parse /etc/env and
And I disargee with this. Requiring all shells be specially modified is bad.
Rather, I think update-env should generate /etc/env.bash, /etc/env.csh, etc,
and shells should simply souce those files.
--
see shy jo
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: