I've informed Ion and kdelibs3-unified maintainer (who was the same). Tolua is being revised by me, so that will move to lua51 shortly.
The original 'lua' package is old, and in my understanding no longer supported. It does conflict with 'lua51', which uses update- alternatives for the 'lua' command (update-alternatives are great, btw!). Now, how should we _really_ deprecate 'lua' package? Users will easily just 'fink install lua' and they'd get the old version. This sucks. Is there a way to totally ban its usage. Maybe I should make a new version (5.1.3) that would only require the lua51 (or whichever is latest) Lua package. Actually, I will do that. The reason for the name change has been that Lua 5.x is not intended fully compatible with Lua 5.y. Thus, it makes sense to package and maintain them separately. The new packaging allows several versions to peacefully co-exist. Just using 'lua' package must stop. About the original issue: One way would be to require the _user_ to manually do 'lua install lua51-dev' so that LuaRocks will be able to compile Lua modules. This would not shake the fink systems, and is kind of understandable in my opinion. The end of installing LuaRocks would show something like: *** *** Please run the following command to allow LuaRocks install binary modules *** *** sudo fink install lua51-dev *** -asko Jean-François Mertens kirjoitti 14.5.2008 kello 2:31: > > On 13 May 2008, at 20:59, Asko Kauppi wrote: > >> >> I need advice on how to deal with this. Luckily, I am the author of >> both lua51 and (upcoming) luarocks packages. >> >> 'lua51-dev' package has the developer tools (headers) for compiling >> code against Lua 5.1 (liblua). >> >> Normally, packages would only need this for their building, but >> luarocks (similar to Ruby Gems but for Lua addon packages) might need >> it anytime. Since the user can say "luarocks install" and rocks might >> need Lua headers to be around. >> >> So should I simply raise (remove) "BuildDepends only" from the lua51- >> dev package, or is there some better approach? >> >> If I do this, will lua51-dev still be allowed into the stable tree? >> >> "headers and the final links from libfoo.dylib into a package which >> is classified as BuildDependsOnly: True, and plan to have no other >> package depend on this one" >> "A maintainer who has reasons to deviate from this policy and not >> split the package should explain the reasons in the DescPackaging >> field." > > Have no specific comments as to the above, except that it corresponds > to a longstanding problem ( note the BuildDependsOnly fields in lua > and lua51 > do not correspond: one is "true" while the other is "false" ..). > So very happy you're bringing it up ... > > A quick grep shows the following dependencies : > > kdelibs3-unified: bdep on lua (>= 5.0-1) > kdelibs3-unified-shlibs: dep on lua-shlibs (>= 5.0-1) > .. not too bad.. (but still, for a recent pkg, why should it depend > on such an old lua ..) > > ion: dep on lua (>= 5.0.2-1) > similarly tolua deps on lua > > lua : > Conflicts: lua51, lua51-dev > BuildDependsOnly: false > > lua51-dev : > Conflicts: lua (<< 5.1) > > lua51 : > Conflicts: lua (<< 5.1) > > All other pkgs in fink (10.4/unstable) depend on lua51-shlibs and > bdep on lua51-dev > (e.g. wireshark(-ssl) , nmap _ or tolua in tracker..) > (and I once tried to rebuild ion with lua51, but no way as far > as I remember _ probably too old a pkg (%v=20040729) _ > to build ion as is.) > > The upshot is that whenever some of those other pkgs has to be updated > the build breaks down _ till the next day when seeing what went wrong, > and using --force- _ because ion prevents lua to be removed... > > This experience suggests the "BuildDependsOnly: false" possibility > (which is the > one that allows ion to depend on lua) is dangerous in this context ... > > I don't know what to suggest here _ possibly refactoring lua itself > according to > the scheme in lua51 might help; anyway, rather an a > "BuildDependsOnly: false" > I would rather suggest trying to use maybe update-alternatives, and > a warning > in "DescUsage" that the user wanting use to use the pkg has to make > sure > lua(xyz-whatever) is installed ... > > But as an immediate fix, I would strongly suggest getting in touch > with the > maintainer of ion and KDE, to urge him to see if he cannot upgrade the > pkgs to work with lua51 .. > > JF Mertens ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
