On 28/02/11 at 11:02 -0300, Antonio Terceiro wrote: > Lucas Nussbaum escreveu isso aí: > > Hi, > > > > I'm resurecting this subthread to discuss the naming of packages. > > > > On 19/01/11 at 12:56 -0600, Gunnar Wolf wrote: > > > Agree. And maybe it's overkill to separate just the library from an > > > eight line long program (the case of haml, sass, html2haml, css2sass, > > > ...) to keep things clean. But OTOH, here it would be worth analyzing > > > what are we aiming at with each individual package - I picked > > > libhaml-ruby as an example, so: > > > > > > - Is it a library? If so, it deservers having the 'ruby' particle in > > > the name. And IMO it benefits from being ^lib, as it is clearer > > > > > > - Is it an application? Yes, users can benefit from manually > > > converting between HTML and HAML from the command-line. If used so, > > > and being a bit overzealous on Policy 10.4, users should not care > > > what language it is implemented in - So the package could just be > > > called 'haml', not 'ruby-haml'. > > > > > > - Does it have both? It can/should(?) be split into just the libraries > > > (libhaml-ruby) and the executables (haml, which incidentally happens > > > to be implemented in Ruby). > > > > Regarding library-only packages (an example is nokogiri), I think that > > we should go for binary package ruby-nokogiri, for various reasons given > > in that thread, and I think that the consensus is against keeping the > > current lib.*-ruby naming convention. > > > > Now, there are more problems to solve: > > > > 1) organization of binary packages for source packages that mix > > libraries and applications > > > > If the main use of the software is as a library, and the binaries are > > only there as support, it makes sense to stick with ruby-*. > > If, instead, the main use is as application, we could drop "ruby-". > > And if unsure, ask the list ;) > > That would result in packages named: > > chef > > rails > > rubygems > > puppet > > .. > > Useless splits with several binary packages should be avoided. For > > example, if shipping the binary with the library adds less than 20% to > > the size of the library package, the packages should be merged. > > Just wanted to point out that if we replace "ruby-*" with "lib*-ruby" in > the above, that is already our de facto practice; it is nice to > explictly standardize on it. > > > 2) naming of source packages > > > > I think that we should get rid of lib.*-ruby source packages, even if > > that means slightly more work for us. > > And to replace them, I think that packages should be named the same as > > the main binary package for the package. So ruby-*, or directly "chef", > > "puppet", etc. > > Agreed to.
OK, but then we have a problem: gem2deb currently generates source packages named like the gem. This might be OK as a default, but I think that we should have an option to switch to ruby-* source naming. Anyone willing to make the changes? In the meantime, I will make a first upload of the gem2deb package to Debian experimental. The other changes (installation of gemspec ; ruby-* source name) can wait for the next upload. I'll post the link of the wiki page to -devel@ shortly, too. I think that the plan could be: - upload gem2deb to experimental - upload updated interpreter packages to experimental - update a dozen of libs to use gem2deb, upload to experimental If everything is fine at this point, move everything to unstable. Comments? - Lucas -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
