Re: Naming of source and binary packages (Was: Ruby packaging in wheezy: gem2deb, new policy, etc.)
- To: debian-ruby@lists.debian.org
- Subject: Re: Naming of source and binary packages (Was: Ruby packaging in wheezy: gem2deb, new policy, etc.)
- From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
- Date: Fri, 4 Mar 2011 10:02:08 +0100
- Message-id: <[🔎] 20110304090203.GA3752@xanadu.blop.info>
- In-reply-to: <20110228140227.GB7425@softwarelivre.org>
- References: <20110116224924.GA13341@xanadu.blop.info> <20110118182603.GI30470@gwolf.org> <20110118192722.GA13760@xanadu.blop.info> <20110119185625.GF4574@gwolf.org> <20110227082542.GA14279@xanadu.blop.info> <20110228140227.GB7425@softwarelivre.org>
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
Reply to: