On 15.09.2012 04:13:49, Hisham wrote: > On Thu, Sep 13, 2012 at 4:26 AM, Ildar Mulyukov > <[email protected]> wrote: > > So speaking of LR, if it's a Package Management System, then it > > probably shouldn't handle multi-trees in terms of deps checking. > PERIOD. > > I disagree. Just because RPM and DEB don't handle multi-trees (and I'm
It's not "just", there's something that caused that. > not even sure they don't, it's been a long time since I last looked at > them), it doesn't mean that no pacakge manager can ever have this > feature. emm, have a good example? Any single package manager that works that way? In fact there are good reasons for that. Some of the reasons you already mentioned yourself: inter-tree deps, control mechanisms, etc. > > But if treating LR as "packaging of what is in $LUA_PATH", then > there > > could be an alternative design: > > 1. LR follows $LUA_PATH and handles multi-tree according to it. > > $LUA_CPATH should be taken into account too. > > 2a. -||- > > 2b. LR shall control deps. > > 2c. manifest file existence and placement should be rethought. > > > > Need to elaborate further. But for now what do you think? > > Item 1 would be a great idea if LUA_PATH was not so free-form. We > could kind-of guess the LR trees and their precedence from a > well-behaved LUA_PATH, but we can't really count on this. Yes, surely. But that'd be really natural. Please, think of it. > On item 2c, we did change that from LuaRocks 1.x to 2.x, in order to > make things more controlled and to be compatible with the standard > layout expected by vanilla LUA_PATH. > > I don't think the big challange now is about placement and the > manifest really, but rather about defining the behavior of the tool in > the presence of multiple configured trees. Agreed. I mean that having changed the behavior would most probably cause another change in this area. Anyway, it useless to argue about this until the behavior question get resolved. > Some concrete questions: > > * Should LuaRocks allow the installation of rocks in a tree if its > dependencies are installed in another tree? > * Should this behavior to be the default? > * Should any other configured tree match, or should there be criteria > for this "other tree" to be accepted (Example: /usr/local depends on > /usr, not vice versa) > * How about the user tree? (Scenario: What if the sysadmin uninstalls > a rock and breaks the user's tree? Do we care?) Allright, I have one more thing to propose: usecases. (the scenarios you already started to quote here). Let me add here a couple. 0. This is about a user who wants to use a piece of software on his Linux box (some Linux FHS-compliant distro, like Fedora or Ubuntu) 1. The user, who has admin rights, installs the software (a rock, e.g. Sputnik) _systemwide_ with this command: <fill the command here> and launches it with this command: <another command> 2. The user, who has _no_ admin rights, installs the software (a rock, e.g. Sputnik) _locally_ with this command: <fill the command here> and launches it with this command: <another command> 3. A rock in system tree (/usr) is removed by another (admin) user. and so on. When you get a full set of _reasonable_ usecases, you can compare them to what we have now and may have an idea what's missing and, maybe, what we should get rid of. I humbly hope this helps. Regards, -- Ildar Mulyukov, free SW designer/programmer ================================================ email: [email protected] blog: http://johan-notes.blogspot.com/ ALT Linux Sisyphus ================================================ ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Luarocks-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/luarocks-developers
