On Sun, 10 Sep 2006 21:33:54 +0200, Hisham Muhammad <[EMAIL PROTECTED]>  
wrote:

> On 9/10/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
>> On Sat, 09 Sep 2006 19:28:28 +0200, Hisham Muhammad  
>> <[EMAIL PROTECTED]>
>> wrote:
>>
>> > On 9/9/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
>> >> On Sat, 09 Sep 2006 17:15:25 +0200, Hisham Muhammad
>> >> <[EMAIL PROTECTED]>
>> >> wrote:
>> >>
>> >> > On 9/9/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
>> >> >>   Added installation of unmanaged files to SymlinkProgram
>> >> >
>> >> > Installation of unmanaged files is/should not be made at
>> >> > SymlinkProgram, but at InstallPackage and Compile. You don't want
>> >> > unmanaged files to be re-copied every time you switch versions  
>> using
>> >> > SymlinkProgram, for example.
>> >> >
>> >> As one, at least I, wants to remove the files when one uses
>> >> RemoveProgram,
>> >> and presumably with DisablePrograms as well, there should be a way to
>> >> get
>> >> the files back into place without having to Compile/unpack the entire
>> >> application. I could add a check to see if the file exists, or just
>> >> remove
>> >> the '-f', but then again there could be version specific unmanaged
>> >> files,
>> >> like the kernel module for rlocate, and therefore it needs to be  
>> copied
>> >> everytime one switches version with SymlinkProgram.
>> >
>> > Agreed. Maybe SymlinkProgram can have a --unmanaged flag instead, and
>> > do "ask" when called from the command line (and act automatically when
>> > called from InstallPackage and Compile?).
>> >
>> Instead of having it boolean as it is today?
>
> Yes. The idea being that the default behavior of calling
> SymlinkProgram from the command line without extra flags would not
> copy over stuff automatically.
>
Commited. But I haven't changed how Compile and InstallPackage invokes  
symlink program, as I wasn't sure what was good defaults. Perhaps one  
should be able to tell Compile and InstallPackage what one would like to  
do with unmanaged files and for Compile, maybe it even could be a recipe  
variable. The danger as I see it is if, as you said, var stuff would be  
put into unmanaged, do you really want to overwrite that when a new  
version of the app is Compiled?

>> >> >>   Made installation of unmanaged files use hard links and fall  
>> back to
>> >> >> copy
>> >> >
>> >> > Hard links are a bad idea for installation of unmanaged files,  
>> because
>> >> > when you edit a file in the unmanaged location, it will modify the
>> >> > files under Resources/ (this will "taint" the program, will break
>> >> > signature verification and make it easy to get site-specific stuff
>> >> > stored by accident in packages).
>> >> >
>> >> Fair enough, but perhaps you should have mentioned this in the thread
>> >> "Suggestions to Compile"?
>> >
>> > Yes, I should have, my bad. :( I haven't followed the list as closely
>> > as I should have the last few days. Sorry about catching this only
>> > after the commit.
>> >
>> > For the space-conscious, maybe this could become a configurable
>> > setting, a settable flag in some .conf file under Settings/Scripts.
>> > I'm not really sure if the saved space is worth the effort (and the
>> > risk of messing with packages) but still.
>> >
>> I fail to see this risk as I can't see any dynamic files going into
>> unmanaged.
>>
>> >> Otoh, most unmanaged files are static (aren't all), so this  
>> shouldn't be
>> >> an issue(?).
>> >
>> > Not necessarily. Var stuff is 'variable' by nature...
>> >
>> Well, the name gives it away. :)
>> I wasn't aware that var stuff should go to unmanaged. Are you meaning  
>> /var
>> stuff or other variable stuff? If the former, I must have missed that
>> information, when was that decided, and if the latter, I can't really  
>> see
>> any variable files that _have_ to be in unmanaged, but can be forced  
>> into
>> some of the managed directories under /Programs
>
> Yes, I'm meaning /var files. I don't have examples to back up my point
> right now, but I _think_ some /var stuff would end up at unmanaged.
>
I don't think this is a good idea, for the reasons stated above. Why can't  
that var stuff be placed in /Program/Foo/Variable?

> So, to summarize, I understood the need for the installation of
> unmanaged files going to SymlinkProgram; I'd just prefer it not to do
> it by default every time (and not use hard links by default too).
>
Ok, I've rolled back the linking and added possibility to make  
SymlinkProgram ask, install or skip unmanaged files (default is ask).

-- 
/Jonas

PS. there's nothing wrong with a qwerty keyboard. I type on one everyday...
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

Reply via email to