On Wednesday 28 September 2005 07:35 pm, Mauricio FernáÏdez wrote: > Can we move on now? We've seen random insulting, bashing of specific > OSes and projects, outrage bursts and FUD accusations... > > Could we focus on what needs to be done, and how it's going to > happen? Thank you! Yes, let's get down to details! > * [... gem contents depending on gem software ... particularly require_gem > and DATADIR issues ...] Other than these two issues, are there other kinds gem references that cause problems ... or is this the bulk of it? > * These issues affect all the systems that don't manage Ruby packages > the way RubyGems does it (most predate it). I'm being told so > by Debian, PLD and Suse developers (I haven't been able to get in touch > with other repackagers yet). I was also told so by a FreeBSD > developer, but at least one FreeBSD developer disagrees with him or > thinks that wrapping gem install is an acceptable compromise for the > system. It is important to differentiate between the gems runtime and the gems package format. AFAIK, there is nothing in the package format that makes it any worse than, say a tar file. Yes, there are things to make it even easier (e.g. more metadata, better identification of arch dependent vs arch independent files), but it seems to me that starting with a gem should be easier than starting with a raw tar file. Take the rake project for example. Rake is distributed as both a gem and a tar file. Given that the same software is delivered in both package formats, would you prefer to start with the tar file? And if so, why? What specific changes would make it easier for repackagers? Thanks for any feedback. Really. > _why proposed a list [ruby-core:5877] and further refined it in > [ruby-core:5950]; the latter incorporated items added by Chad Fowler > [ruby-core:5880] and Jim Weirich, who also prioritized them in > [ruby-core:5901], without specifying the sorting criteria, though. > Austin Ziegler created the so far most detailed list [ruby-core:5882]. > I tried to assign priorities to the latter based on the impact on > upstream code in [ruby-core:5890]. Unfortunately, the latter was largely > disregarded, but I'd appreciate constructive criticism. We are mainly working from Why's list, concentrating on the higher priority items first. Austin's list had some good suggestions, but I didn't see anything that would fall in the high priority list that wasn't already there. Once the high priority items are ticked off, we will surely revisit the list. BTW, let me just add that I am a Debian user and one of the things that drew me to the distro was its packaging system. I certainly don't want to do anything to discourage the packaging of ruby software (gem or otherwise) as debian packages. If someone wants to manage their system entirely as debian packages, more power to them ... and I hope that gemified ruby software is readily available in that format (and that goes for RPMs and FreeBSD ports as well). -- -- Jim Weirich jim / weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) P.S. I will be at the Ohio Linuxfest this weekend (http://ohiolinux.org/). It just occurred to me that there is a greater than zero chance that a number of Debian developers might be attending; and a smaller but still non-zero chance that some of those Debian developers might be interested in Ruby as well. If you, or someone you know falls in that category, feel free to drop me an email and we can try to meet up. I'd love to talk through some of these issues.