[gobolinux-devel] Re: "backlinked" variable

[Jonas Karlsson]

Having some time to think through this and some other things to shed light  
on it I can now reply to this and describe why I made the post the first  
time.

On Wed, 26 Jul 2006 21:52:15 +0200, Hisham Muhammad <hisham.hm at gmail.com>  
wrote:

> On 7/16/06, Jonas Karlsson <jonka750 at student.liu.se> wrote:
>> Why are the directories in /S/V linked to the programs instead of the
>> programs linked to /S/V like in all other links? Is there a good reason?
>> The reason I ask is because programs fail at installation when trying to
>> install anything int $variable_target if a previous installation of any
>> version of the same program is left. This is because fibo has no rights  
>> to
>> write into /S/V where the link is pointing...
>> Any good solution to this problem?
>
> Unfortunately, I can see none.
>
I have some idea now, see below.

> I had many on- and off-list discussions about the Variable problem,
> and could never reach a good solution. _Right now_ my opinion is that
> we should just dump stuff in /System/Variable and leave it unmanaged
> there, have the machine's admin decide when stuff should be removed
> from there (because there are semantic subtleties: one would probably
> want updatedb files to be removed when Locate is uninstalled, but
> someone else wouldn't want their Apache logs to be removed if Apache
> is removed).
>
Problem with dumping things in variable is that, as you said below, fibo  
doesn't have write permissions there.
Why can't we have Variable the way Settings work? If one removes a  
program, using RemoveProgram, the Settings directory is kept. The same  
would apply for Variable.
The "problem" here could be that some users like to have their /var on  
another partition and therefore have the files on that partition. I have a  
solution for that below.

> The "backlink" approach was an attempt to have some kind of management
> over /var, but that never worked 100% (as the problems you mentioned
> show). Currently, my opinion is that we get rid of /P/Foo/Variable and
> handle stuff in /var using the Unmanaged feature recently introduced.
> Maybe /P/Foo/Variable is useful for fibo, roughly as in:
>
> mkdir /P/Foo/Variable
> as fibo, make install: stuff is dropped in /P/Foo/Variable
> mv /P/Foo/Variable/* /System/Variable
> rmdir /P/Foo/Variable
> ln -nfs /System/Variable /P/Foo/Variable
>
> But we'd have to do that dance only if giving fibo write permissions
> in /S/V is problematic. (For unionsandbox that's not an issue.)
>
This could still work, with a small modification. The problem now is that  
after first installation the /Programs/Variable points to  
/System/Variable, where fibo has no write permission, which cause install  
to die. If one instead do like Settings do and move the current Variable  
link to Variable.hold, make a link from /Program/Foo/Variable to  
Foo/x.yy/Resources/Unmanaged/System/Variable. Then after install that  
latter link is removed and the former is restored. It's important though  
that InstallUnmanaged does not overwrite existing files, even if the dates  
are newer. People might want to keep their logs and databases.

-- 
/Jonas

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/