similar, but 'gobo' is in the details :)...
If you have the rev links in a subfolder...if  the folder is deleted 
then the reverse dependencies are lost...the right place is 
/System/Links...which can be backed up as needed

The primary concerns in that response are to do with 'maintaining' the 
links up to date ...however going back to this point:

[EMAIL PROTECTED] wrote:

> An optimization over that would be to look at UsedBy entries of other
> versions of libA that are already installed, check the dependency
> files of programs mentioned there (like programB/1.1 in libA/3.0) and
> only check those, to see if the range they describe are valid. This
> however, assumes that the all dependencies are properly satisfied by
> the time something is installed, which is often not the case.

Even if some dependency is not satisfied, the link for that can still be 
created in the /System/Links/Dependency/<package-name> to indicate that 
progrm depends on this...reverse dependency check can be done using the 
Dependency files on a as needed basis  when the information seems out of 
sync...

The link system provide a quick way of making sure that if no links are 
broken the system then things are 'ok' ....instead of a file based check 
for something and links to /Programs for others....

Here is a sample based on the lib example given earlier:

>/ For example if we have four versions of libA,
/>/
/>/ libA/1.0
/>/ libA/2.0
/>/ libA/3.0
/>/ libA/4.0
/>/
/>/ then install programB/1.1 which depends on libA >= 2.0 and libA <= 3.0,
/>/ programB will be symlinked to/

/System/Links/Dependency/
                                            libA/
                                                   <=3.0/
                                                                
programB-1.1 -> /Programs/programB/1.1
                                                   >=2.0/
                                                                
programB-1.1 -> /Programs/programB/1.1
 
Note: creating these links does not need the library installed first
Now if you had to remove libA/1.0, you would check that no = or <= 1.0 
exists, if a >= 1.0 exists then you check that a >= 1.0 exists in libA 
(which is 2.0) ...and then u remove it...
Similarly for others...

What say?

- Anshuman

[EMAIL PROTECTED] wrote:
> On 7/2/07, Anshuman Aggarwal <[EMAIL PROTECTED]> wrote:
>   
>> Thanks, I was convinced this (link based) approach is perfect for
>> gobo...but the lack of response was worrying me :) ...I will document
>> the details on the wiki and send out a link...then if everyone is in
>> agreement we can work out a plan of introducing it into gobo scripts.
>>     
>
> I can surely be wrong, but my understanding of this proposal is that
> it is, in essence, equivalent to what Jan Molič presented here:
>
> http://lists.gobolinux.org/pipermail/gobolinux-users/2007-June/005906.html
>
> except that links are grouped under /System/Links/Dependencies rather
> than stored inside each /Programs entry as UsedBy. (Except of course
> for technicalities such as naming and the use of ranges.)
>
> My concerns about it are the same as the ones I presented here:
>
> http://lists.gobolinux.org/pipermail/gobolinux-users/2007-June/005911.html
>
> It has to do mainly with the order of installations. Following the
> thread linked above, a conclusion was that perhaps global checking is
> not that expensive, and has advantages such as avoiding duplication of
> information and ensuring consistency. (But note the "perhaps").
>
> -- Hisham
> _______________________________________________
> gobolinux-devel mailing list
> gobolinux-devel@lists.gobolinux.org
> http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
>   
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Reply via email to