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 <[EMAIL PROTECTED]>
wrote:
On 7/16/06, Jonas Karlsson <[EMAIL PROTECTED]> 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/
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
