From: Hugh Sasse Date: 2005-10-17T23:47:18+09:00 Subject: Re: RubyGems, upstream releases and idempotence of packaging ---559023410-1903590565-1129559607=:10996 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1903590565-1129559607=:10996" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1903590565-1129559607=:10996 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 17 Oct 2005, Gavin Sinclair wrote: > On 10/17/05, Mauricio Fern=E1ndez wrote: > > We're considering the following alternatives (the initial assumption is > > that we want repackaging to happen so that end users can install Ruby > > software the way they choose --- or they're allowed to): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thi= s is the important aspect: >=20 > Yes, valid assumption, but my point is about "repackaging" gems vs > "packaging" pristine sources. The goal ("end users can install...") > isn't necessarily hampered by gems being repackager-unfriendly.=20 It is in the case where the user wants to install the gem as it would be installed by their packager, so that they use "one tool to manage them all, one tool to find them". > That's the point I want to see argued. >=20 > If the answer is "that's true, but there's so much to be gained from > making gems repackager-friendly", that's fine. But I want to be clear This is the thrust of the argument. It makes repackagers happier, it makes people who will only install things as packages happier, and it reduces noise on the list. > that that's the answer. >=20 > > * accept the status quo: do to the "binary" nature of RubyGems packages= , > > often attempts to repackage them involve: > > * requests to the upstream developer for the pristine sources >=20 > That's not repackaging a gem, that's packaging some pristine sources.=20 > The gem is incendenary and not involved. Saying that "repackaging gem "incendenary"? Nearest match I can come up with for that is "incendiary" :-) Liable to create flame wars :-) ? > Z" involves such effort is misleading. You don't repackage binary > distributions. I think, from the context of the discussions so far, this is about not having all the files and information necessary to create an RPM or other package because the information about what can be moved around to data directories or whatever is missing in the gem. So you ask the author for the information, original directory structure or something. >=20 > > * patching by the repackager (or the upstream developer) to ensure > > the software works without depending on RubyGems >=20 > It's perfectly reasonable for a gem distribution of software to depend > on RubyGems, and it's unreasonable to complain about the effort in > removing that dependency. My point in the "discuss" paragraph is that > it's up to the author to decide what dependencies they want in the > code. A Debian repackager is welcome to make a package of the same or > different code, but they are not welcome to complain that a .gem file > contains a dependency on RubyGems! Except that they argue it makes life more difficult, because rubygems doesn't handle packaging issues as they need it to, so they don't want to have it, then having software depend on it locks them out. The line of thinking is "gems are meant to make things easier for people, but for those who use one packaging system for their machine it makes things more difficult, and can something be done about it, please?" =20 >=20 > > * provide a mechanism to make it easy to give repackagers the input the= y need > > without affecting RubyGems' capabilities. >=20 > So that's the second alternative? I don't understand what it means.=20 > What's "the input they need"? The files they would need to create a package, having squeezed the gem to get them out (using unpack or some other method). My point about binary gems was due to the desire to still have them for platforms/situations where it makes sense. Clearly one cannot repackage from a binary gem. >=20 HTH, and hope that I haven'd distorted anything, Hugh ---559023410-1903590565-1129559607=:10996-- ---559023410-1903590565-1129559607=:10996--