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
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
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
10:58 < ferdy> user-defined stuff is annoying when it comes to man-pages
and other files too
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<---
- ferdy
pgplMEFDFySRI.pgp
Description: PGP signature
_______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
