dependency aliases

[Chad Kittel]

On Wednesday 06 October 2004 02:00 am, Auke Kok wrote:
> 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 ;^)
>

:o)

> >>* 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.

Thank you for the explanation, that is was I guessed was meant by that, but 
wasn't 100%.

>
> >>* 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 ;^)

Well, you have completely answered all of my up front questions so that I feel 
that I'm not guessing at desired behavior when I start testing, Thanx.  
Hopefully after work today (or tomorrow) the testing shall begin on my side.  
I would encurage others to also join in if they have the time, I think this 
new feature really adds a flexability and "cleanness" to the depends that was 
really lacking before and the sooner sofar gets proper and complete responses 
back from us the sooner this can be officially implemented.  YaY

- v3rt1g0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lunar-linux.org/mailman/private/lunar-dev/attachments/20041006/696c3b0a/attachment.bin