[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: