dependency aliases

[Auke Kok]

Chad Kittel wrote:

>On Tuesday 05 October 2004 10:33 am, Auke Kok wrote:
>  
>
>>attached is a rough draft for theedge (current) that implements aliases
>>for dependencies in the following way
>>    
>>
>This is great, thank you sofar (and anyone else who may have worked on it).  I 
>have not yet untared it in order to test/try, because I wanted to ask some 
>questions upfront and give some immedate feedback
>  
>
>>* unalias() function that translate module names to aliases if it starts
>>with '%'
>>
>>* /var/lib/lunar/aliases is the known aliases db and alternatives
>>    
>>
>Is there any alias naming restrictions?  such as:
>%SameName:SameName DifferentName
>  
>
that's allowed since '%something' is an alias and 'something' is not. 
They are two disticnt words in any case. anything starting with a '%' is 
an alias. This will make it easier later on to port the old code and add 
the right hooks.

>Where the alias's name is the name of an existing module (either part of that 
>alias or maybe just the name of another module in the moonbase)... basicaly 
>does the alias name need to be unique thoughout the moonbase?
>  
>
the name -no-, the alias name '%name' yes of course. Again, you can have 
%sendmail and sendmail coexist (although that is very confusing).

my test example exists of an alias '%X' which aliases to XOrg, xfree86 
and xfree86-beta

>I don't suppose you can have something like:
>%Alias0:ModuleX ModuleY %Alias1
>Where an alias is expanded inline.  This could cause some nasty recursion now 
>that I think of it...
>  
>
the unalias function is non-recursive. I think I'd like to keep it that 
way, after all we're not writing the core code in oobash ;^)

>>* first found pick is go (we basically keep it to *exclusive* aliases,
>>sorry for now that is it)
>>    
>>
>What is meant by this?  
>  
>
when unaliasing "%X:A B C", the algorithm searches to see if the alias 
can be satisfied automatically and checks if alternatives A, B or C are 
installed (in that order). As soon as the first alternative is found to 
be installed, it is aliased to that alternative, and no further searches 
are done on any following alternatives.

>  
>
>>* if you replace xfree86 with XOrg every dependency is automatically
>>updated when a module is relinned, so impact on move is minimal
>>    
>>
This might not be as flexible as I thought, however, a lunar fixdepends 
should convert all aliased modules to another alternative in case the 
first one is removed (like when switching from xfree86 to XOrg)

>>* lvu stree/tree also ported to include the functionality
>>
>>* provide a picklist in case no alias is installed (this is *VERY* rough
>>code, a bit hacked).
>>
>>it works OK with my little test cases so far, I think you guys wanna
>>test this and tell me how it behaves for you badly ;^)
>>    
>>
>Can you give us an example usage in a DEPENDS file?
>I'm assuming it would it be like...
>depends RealModule
>depends %ModuleAlias
>  
>
correct. I made a gtk+/DEPENDS with 'depends glib && depends %X'

>optional_depends %AnotherModuleAlias "--enable-somethingcommon" "" "for 
>something special"
>  
>
yup, optional depends also works (this is nasty of course!)

>Looking forward to this... It will certainly help module developers.
>- v3rt1g0
>  
>

since this is an API change it needs to be considered and rolled out in 
the core before we do moonbase, so we *NEED* to test this thoroughly 
before we can rool it out. Just a hint ;^)

sofar