On Mon, 8 Sep 2008 11:11:55 +0200 "Fernando J. Pereda" <[EMAIL PROTECTED]> wrote:
> We've been discussing alternatives a bit this morning. I think we are > interested in use cases so we can see exactly what alternatives has to > do: > > ---8<--- > 10:44 < Ingmar> Alternatives for perl, discuss :) > 10:44 < Ingmar> as in, eselect alternatives > 10:45 < ahf> ruby? > 10:45 < ahf> oh > 10:45 < ahf> never mind > 10:45 * Ingmar slaps ahf around > 10:45 < Ingmar> :) > 10:47 < ferdy> this is something that has been in my mind about > eselect alternatives: it should understand 'systems' or > 'modules' (like perl, ruby, mta ...) and for each module have the > files it has to manage, each provider has to specify paths for all > managed files 10:48 < ferdy> it should actually use hardlinks for > executables instead of having a 'smart binary' or symlinks > 10:49 < ferdy> 'smart binary' is the mailwrapper approach. Basically > you install mailwrapper wherever you want and it decides what to run > depending on a configuration file. Which means it parses the file > for every frigging call. 10:52 < ferdy> module/system definitions > should come in a separate exheres and the exlib would sort > dependencies for you (like ALTERNATIVES_SYSTEMS="one two" before > requiring alternatives.exlib) > 10:53 < dleverton_> I really don't want to have a seperate exheres for > each one. > 10:53 < dleverton_> That just adds a ton of clutter. > 10:54 < ferdy> then you need to have all providers agree on the same > module definition What, like, what module they provide? I think for most things that'd be pretty straight-forward... As far as the format of the files themselves, it's already documented[1]. > 10:54 < dleverton_> Yes. > 10:54 < ferdy> which is fine, it is just more work > 10:54 < dleverton_> Which isn't ideal either, but better IMHO. > 10:55 < dleverton_> Also, why hardlinks? > 10:55 < dleverton_> I hate hardlinks. :-( > 10:55 < spb> because hardlinks are cool I also hate hardlinks. > 10:55 < dleverton_> Also, we need the smart binary thing if we want to > make it settable per-users. > 10:55 < dleverton_> *user > 10:56 < zlin> which makes a hell of a lot more sense for an editor > than an mta 10:56 < ferdy> if you have an application that calls > sendmail a lot, you really don't want mailwrapper to consume most of > the time 10:56 < ferdy> (and yes, that happened to me once ....) > 10:57 < Ingmar> Definitely not > 10:57 < Ingmar> Same for perl & ruby really > 10:57 < ferdy> which is why I came to hate that approach, but > dleverton_ has a point anyway > 10:57 < zlin> so if we are getting that fancy, we can still support a > wrapper for editors only Yeah, I see your point for things like MTAs. Probably the easiest thing is to add a key, like WRAPPER=NO, to the config file. Then, rather than making a symlink to the wrapper script, it makes a symlink to the targeted executable. When that key is detected, setting per-user defaults is also disabled. > 10:58 < ferdy> user-defined stuff is annoying when it comes to > man-pages and other files too Ya, I wasn't going to do that on a per-user basis. Only reasonable way I could think of doing that was munging MANPATH or something, but that's pretty icky. > 10:58 < kloeri> zlin: good point - some things being per-user and > other things system-wide is probably a good idea > 10:58 < ferdy> I guess we have to make the whole thing a bit more > complex then. 10:58 < ferdy> that's it > 10:59 < ferdy> also, I wonder if per-user stuff can be done adding a > special component to user's PATH > 11:02 < ferdy> shall I list it? > 11:03 < kloeri> yeah, probably a good idea to discuss the different > problems and solutions on the list > 11:03 < Ingmar> yeah > 11:04 < dleverton_> Sure. > 11:04 < kloeri> if nothing else we'll have an archive of it that way > 11:04 < Ingmar> Can I push this perl stuff, creating links in > pkg_postinst for now? Once I test it a bit more.. > 11:05 < dleverton_> (Also, do we want to bother with alternatives for > editors? Can't we just let people set $EDITOR?) > 11:05 < ferdy> heh, I'm with dleverton_ here > 11:05 < kloeri> $EDITOR should be fine imo > 11:06 < Ingmar> was there any other use case for the smart binary > approach then? > 11:06 < dleverton_> I think it's just a matter of adding more > flexibility without a terrible amount of effort on our part. > 11:06 < Ingmar> ok > 11:07 < dleverton_> I don't think I can think of anything right now > that would terribly demand it, no. > 11:07 < dleverton_> I wouldn't be too upset if we dropped the idea, I > think. ---8<--- Ok, well, if nobody can think of really useful use cases for this being able to be done on a per-user level, we can just axe all the user/global stuff and just set it all on a global level, using direct symlinks rather than the wrapper. [1] http://git.exherbo.org/?p=exherbo-alternatives.git;a=blob;f=alternatives-desc.5.pod -- Mike Kelly _______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
