From: Ralph Amissah Date: 2005-09-28T16:27:59+09:00 Subject: Re: gems is a language change, not a pkging system ------=_Part_365_17719056.1127892474262 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I'll greatly weaken my post, and give everyone the opportunity to head me off early by admitting, i should not be engaging in this discussion, I know too little o= n the subject, (i have not yet used gems, i have some idea of their capabilities) and have followed only a few related threads and then only with peripheral vision. That said i am "interested" and alarmed enough to make noise now, lest i am made to regret not having done so later, as appears increasingly to be a possibility. Actually (not having followed the discussion in any detail) I speak mostly to give others who are concerned, and more engaged and knowledgeable than myself on the subject, the assurance that they do not speak alone. And in the hope that all kinks that remain as issues for native packagers of ruby libraries and applications (aka repackagers) are ironed out. Once native packagers are no longer concerned, well, i suspect my concerns will have been met, and i will not be concerned either. If that has happened already, well good, things have developed positively, I am late, and we can move on. I wait to hear their reassurance. (it will also be clear that i have had a positive experience with Linux and Debian and have a rather different estimation of the value and importance of native packaging done right. Debian and Ruby, i am very pleased to have spotted both of those). Austin thanks for such an extensive reply we have fundamental differences o= f opinion on several things though. At the end of the day, i will be glad to be wrong= , and for things to go on smoothly should Gems be introduced, without the slightest hiccup for me using my choice of computer system, with the introduction of Gems. Indeed no hiccup is what i seek... and which is why i am slow to like this idea. >Sorry, but the idea -- that is, RubyGems -- works. The problem -- a Ruby >packaging system -- exists. Do you see a solution other than RubyGems >being available? I sure as hell don't, and that's the problem, Ralph. You have no solution, I have no problem (or seldom do). The solution suggested is not equal to, and cannot be, to what i currently have. I only have real reason to welcome it if it promotes or complements the superior native solution i currently have; it is only acceptable if it does not interfere with what i have got: not in the way it installs; not in the (eas of) preparation by others of packages for my system; not technically (or otherwise) in the likelihood of packages being made for my system... Surprise i am a Debian user, i am one of those who currently has things goo= d with his system and tends to complain and fear the possibility of negative change, (especially change promoted by one (or people) who has actually looked at and somehow failed t= o see this goodness in the system of which i speak). >> Work that out, then offer us Gems "in ruby head" >> Whatever you come up with must play WELL with existing packaging >> systems. > >I frankly don't care if it plays well. I never have, I never will. I do care... this is one of the reason i looked round and settled for using Debian. They do care about packaging. The philosophy of taking packaging and packaging systems seriously and making sure that they work well (both by technological means and by means of policy) may be one of the reasons it appears to be so easy for the Debian system to be so much better than so much else, when it comes to packaging (amongst other things)= . They _do_ *care*... always have, even when stumbling with issues along the way, the eye is on the longer term solution, and diverse needs of various developers and users, and in multiple hardware environments... oh and did i say, they don'= t rush into things either, by rush, and the definition of rush traditionally has not been time based, but getting things right. Others must care as well, there are other decent native packaging systems out there. That said a language packaging system must play well with existing native packaging systems, it cannot replace them, (especially not for general users). It plays well at the very least if not able to help, by making sure it does not hinder, making sure it gets and stays out of their way. (Given that it is being designed from the groun= d up for Ruby, it should take into account these interests and be designed also to help). >I *am* offering proposals that, if provided, should help. ok, glad to hear it, i am sure they go some way towards meeting them. If the native packagers say your proposals achieve what needs to be done, fine. My only concern is this. Get it (Gems whatever) right before anything goes in. Given the fact that these concerns were expressed at the outset, and still have not been fully met... well, fix them first, then consider. There is no rush= . Not getting this right would be a flaw that depreciates the value of Ruby. There is no hurry. OK if: (a) Gems helps native packagers (ok i am told this is not its' purpose) or at least (b) (i) Gems keeps out of the way of native packagers. and (ii) Gems does not in any way make it less likely that Ruby libs/apps get properly packaged, and (iii) Gems where used installs well without interfering in any way with native packaging systems. (and i assume this must have been worked out) that is good to know, i could use them (as in install things with them) say when developing or in an emergency. But without (a) as regards making packages i am still looking for a ruby packaging system, that takes the first step toward= s doing what i need, and hoped for in a basic Ruby packaging system, certainly one that sought to be integrated so closely into Ruby. Unless gems does (a) I continue to await its arrival and will value its arrival more than Gems. This said i am a bystander, who wishes to ensure that this impinges as little as possible on the beauty of the ecosystem in which Ruby and software generally works for me, it happens to be Debian, but could possibly have been something else. I am perfectly happy that gems should be able to live beside it; but it should not interfere, and in no way should it make packaging for it more difficult= . summary without (a) it seems Ruby is still looking for a Ruby solution(s) that makes it as easy as possible for native OS packagers. It seems further that such a system does not compete with Gems. I am likey to find more value in such tools than in Gems, and am yet to figure out how much benefit there would be from being one standard such system, (i tend towards choice). I don't think gems can seamlessly install Rails and its appendages (mysql etc.) if it can, i don't think gems can seamlessly install them on my system whatever that may be in such a way as it (rails mysql whatever i need to make it run= ) is part of my system, if mysql is already there know and not install that that= ; if libraries are already on my system, i don't want to install them more than once. I don't think gems can seamlessly install SiSU for me, and integrate its parts on my system. This is presumably not what Gems is or should be trying to do. This is largely the realm of native packaging systems, this is why i use them, and why where they work, and Debian for example does, we love them. And this Gems (or whatever alternative might be proposed for *core*) should ideally promote if it is capable, and if it is not, must in no way hinder. >Has anyone seen fit to develop a viable alternative to RubyGems? >The rpa-base effort floundered. So, where's the alternative, Ralph? > >Coming out at this late date -- and without an alternative -- is just >sour grapes. Sour grapes sounds a disingenuous characterization of genuine existing concerns. rpa sought to communicate these needs, and to work with Gems, despite reservations, and went out of their way not to compete with Gems, and even contributed substantial amounts of code to Gems. from what i am reading at this time, it seems rpa should instead have produced a Gems replacement (not rpa that was something different, and it would appear a considerably more difficult task). I don't speak for rpa, i do frequent the irc channel because there has been a lot to be learnt about packaging from people there; and i have been help on occasion by good folk there. [Mostly OT and on Debian] >What I dislike about Debian is the arrogance of the philosophy. > Re arrogance, I would say we have much in common with Debian > >I'm sorry for you, then, because the Debian philosophy is one of >arrogance, not service. I dislike working with Debian developers, in the >main, as much as I dislike working with Gnome developers. Debian, IMO, >represents a colossal failure of open source. > Don't feel sorry for me on this Austin. Debian is a resounding success, with reason and very little promotion. All else apart, the choice offered, well near staggering. As for the individuals involved well, there are no doubt issues. Characters= , some arroganct no doubt, strong views, much like you and i. I think at one time the debian irc channel may have got itself a reputation for being hard, perhaps it still is? But they are individuals, a motley bunch, (and perhaps there i= s a bit of an insider culture or insider cultures there are so many of them), and perhaps sometimes the more aggressive are the ones who get heard. >I personally *would not* choose a pure Debian system for installation on any >of my systems. A Debian-based system that pragmatically solves the >philosophical nonsense behind Debian, perhaps. But not Debian itself. Debian is wonderful technically. If your problem is with Debian philosophy, note only that is similar in a number of ways to that from which Ruby is derived, i am thinking mostly of licenses here. Perhaps you are talking about arrogance again here, i wonder= . did i say, i have a new computer from a software perspective every day, (updated system)? and 15,000 packages to choose from? and that the packagin= g system works?... oh, and it only installs each of those 15,000 things once? except where special circumstances have to be catered for, which it knows about on its own? as a user i am not concerned about what language software i use is written in, only it's utility, oh and i don't need to spend much tim= e on it, (setting up) Debian, i can get on with whatever it is i do on my computer? Love it, and like Ruby, with good reason. On a related note it is hardly surprising that Debian packagers show interest in what Ruby proposes to come up with for packaging system, they are more interested and know more about packaging/packaging systems and packaging policy, than most, and have always looked towards the long term scalability and stability of their systems, even when things have not worked perfectly they have looked towards such ends. We should listen more to them. It is fairly easy to see why it works so much better, than other packaged stuff out there. Incidentally there is a recent decent technical book on Debian: The Debian System: Concepts and Techniques by Martin F. Krafft I have it in a really nice hardback edition, published in Germany, http://www.opensourcepress.de/index.php?26&backPID=3D15&tt_products=3D16 for most of the rest of you it is published in not quite as attractive boun= d form by No Starch Press: http://www.amazon.com/exec/obidos/tg/detail/-/1593270690/ Back to Ruby Core >Matz committed in late 2004 to early 2005 to putting a packaging system >in the core. He very clearly stated that this was not necessarily >RubyGems. In this time, no one has seen fit to create an alternative to >RubyGems. Now that it's time to integrate a *successful* packaging >system into the core, we've got the peanut gallery crawling out of the >woodwork saying "it's a bad idea!" Do they offer an alternative? No. > This one surprises me though, i would have thought that Matz would seek to ensure that a ruby packaging system that worked well with other packaging systems... (and thought he might even have said as much quite early in Gems development?). I thought Gems would have been engineered with such a view i= n mind, whatever else they do, what could Gems, or i be thinking? Why are we still talking about it now. On introducing a system like this inside Ruby the onus should be strongly o= n those seeking to introduce it to satisfy others with an interest in Ruby that it meets their general requirements. >> It is unlikely i will engage further in this debate, but i am sick of >> seeing this shoved as some wonderful solution, and a done deal, if it >> fails as obviously as you and others state it does, in what should be >> one of its more obvious and primary objectives (in addition to >> whatever else it might do for you). > >Sorry, but it has never been an obvious or primary objective that >RubyGems should help people who want to integrate with native packaging >systems in ways that are in and of themselves not compatible with >RubyGems philosophy. The RubyGems developers that I have spoken with >have suggested that solving the Ruby packaging problem has been the most >important thing, and everything else is secondary. > I don't see how anything about ruby packaging can be considered *solved* if it is proposed for ruby core and has failed to take into account this aspect that has been presented as a concern from close to its inception. It's not late, there are things to be done, with or without Gems. Right now get Gems right, then ask to have Gems put in core. If Gems have been put right, fine. If Gems can't be put right, don't. Ralph ------=_Part_365_17719056.1127892474262--